Doc fixs (#3163)

Signed-off-by: Andy Kwok <[email protected]>
opensearch-project · Nov 26, 2024 · 40b5b79 · 40b5b79
1 parent 8b2d01e
commit 40b5b79
Show file tree

Hide file tree

Showing 3 changed files with 3 additions and 3 deletions.
diff --git a/docs/dev/intro-architecture.md b/docs/dev/intro-architecture.md
@@ -12,7 +12,7 @@ In the high level, the OD-SQL Engine could be divided into four major sub-module
 
 * *Parser*: Currently, there are two Lex&Parser coexists. The Druid Lex&Parser is the original one from NLPChina. The input AST of Core Engine is from the Druid Lex&Parser. The [ANTLR](https://github.com/opensearch-project/sql/blob/main/legacy/src/main/antlr/OpenSearchLegacySqlLexer.g4) Lex&Parser is added by us to customized the verification and exception handling.
 * *Analyzer*: The analyzer module take the output from ANTLR Lex&Parser then perform syntax and semantic analyze.
-* *Core Engine*: The QueryAction take the output from Druid Lex&Parser and translate to the OpenSearch DSL if possible. This is an NLPChina original module. The QueryPlanner Builder is added by us to support the JOIN and Post-processing logic. The QueryPlanner will take the take the output from Druid Lex&Parser and build the PhysicalPlan
+* *Core Engine*: The QueryAction take the output from Druid Lex&Parser and translate to the OpenSearch DSL if possible. This is an NLPChina original module. The QueryPlanner Builder is added by us to support the JOIN and Post-processing logic. The QueryPlanner will take the output from Druid Lex&Parser and build the PhysicalPlan
 * *Execution*: The execution module execute QueryAction or QueryPlanner and return the response to the client. Different from the Frontend, Analyzer and Core Engine which running on the Transport Thread and can’t do any blocking operation. The Execution module running on the client threadpool and can perform the blocking operation.
 
 There are also others modules include in the OD-SQL engine.

diff --git a/docs/user/general/datatypes.rst b/docs/user/general/datatypes.rst
@@ -115,7 +115,7 @@ A data type can be converted to another, implicitly or explicitly or impossibly,
 
 The general rules and design tenets for data type conversion include:
 
-1. Implicit conversion is defined by type precedence which is represented by the type hierarchy tree. See `Data Type Conversion in SQL/PPL </docs/dev/TypeConversion.md>`_ for more details.
+1. Implicit conversion is defined by type precedence which is represented by the type hierarchy tree. See `Data Type Conversion in SQL/PPL </docs/dev/query-type-conversion.md>`_ for more details.
 2. Explicit conversion defines the complete set of conversion allowed. If no explicit conversion defined, implicit conversion should be impossible too.
 3. On the other hand, if implicit conversion can occur between 2 types, then explicit conversion should be allowed too.
 4. Conversion within a data type family is considered as conversion between different data representation and should be supported as much as possible.

diff --git a/docs/user/general/identifiers.rst b/docs/user/general/identifiers.rst
@@ -241,7 +241,7 @@ tableName = ``logs.12.13.1``.
 3. ``my_prometheus.http_requests_total``
 
 
-datasourceName = ```my_prometheus`` [Is in the list of datasources configured].
+datasourceName = ``my_prometheus`` [Is in the list of datasources configured].
 
 schemaName = ``default`` [No supported schema found, so default to `default`].