A method for dynamically modifying SQL based on execution feedback

Abstract

The present application relates to a kind of SQL dynamic correction method based on execution feedback.The present application includes receiving candidate SQL, target data source information, Schema context and query semantic context and executing candidate SQL;When execution fails, error code, error text and error location are normalized as error event, and SQL structured representation is formed according to target SQL dialect;Error event is corresponded with SQL structure node, database object and dialect rule, and error analysis result containing positioning state and affected range is obtained;Modification plan of node replacement, clause reconstruction or constrained regeneration is generated according to error analysis result, and modified SQL and modification difference are formed;Modified SQL is checked for dialect structure, Schema existence and semantic maintenance, and re-executed after passing the check, and continue modification, clarification, transfer or termination are determined according to new execution feedback, failure signature, modification history and termination condition.The present application improves the locatability, constraint and closed-loop controllability of SQL modification.

Description

Technical Field

[0001] This invention relates to the fields of database query processing, natural language query generation, and intelligent agent execution technology, and in particular to a method for dynamic SQL correction based on execution feedback. Background Technology

[0002] Existing Text2SQL systems or data analysis agents typically generate candidate SQL statements based on the user's question and the database schema, and then send the candidate SQL statements to the database for execution. Due to differences in target database dialects, schema changes, incorrect table field references, incorrect aliases or joins, incompatible data types, and invalid aggregation and grouping relationships, candidate SQL statements may fail during execution.

[0003] For SQL queries that fail to execute, a common approach is to directly append the error text returned by the database to the generation context and then request the generation module to generate the SQL again. While this approach can utilize some error information, the format and granularity of the error text depend on the database or driver, and it typically only describes the surface error, failing to directly indicate the SQL fragment involved, the database object, or the scope of possible corrections.

[0004] When execution feedback is not converted into a transitive error parsing result, subsequent rewrite processes may repeatedly generate the same or similar erroneous SQL statements. They may also change existing metrics, dimensions, filtering conditions, or time conditions while correcting local errors. On the other hand, execution failures such as permission denial or data source unavailability cannot necessarily be resolved by rewriting the SQL. Failing to distinguish between rewriteable and non-rewriteable errors can easily lead to invalid loops. Summary of the Invention

[0005] Therefore, the technical problem to be solved by the present invention is to overcome the problems in the prior art where the execution feedback granularity, SQL structure granularity and correction action granularity are inconsistent, resulting in unclear error location, uncontrollable SQL rewriting scope, easy unfounded changes in the original query semantics, and lack of clear exit conditions for automatic retries.

[0006] To address the aforementioned technical problems, this invention provides a method for dynamic SQL correction based on execution feedback, comprising: Receive candidate SQL statements and obtain the target data source information, target SQL dialect, schema context, and available upstream query semantic context corresponding to the candidate SQL statements; when the upstream query semantic context is not provided, extract baseline semantic constraints from the candidate SQL statements; determine the upstream query semantic context or the baseline semantic constraints as preconditions semantic constraints, and form a task context based on the candidate SQL statements, the target data source information, the target SQL dialect, the schema context, and the preconditions semantic constraints. Based on the task context, the candidate SQL is submitted to the target data source; when the execution is successful, the candidate SQL is output as executable SQL and the current correction process ends; when the execution fails, the error code, error text, error location and execution environment information corresponding to this execution are obtained, and execution failure information is generated accordingly. Based on the candidate SQL, the execution failure information, the execution environment information, the schema context, the pre-semantic constraints, and the correction history, a structured execution feedback object is constructed, and the heterogeneous execution failure information in the structured execution feedback object is normalized to obtain normalized error events. The candidate SQL is parsed according to the target SQL dialect to form a structured representation of SQL that includes query level, clause type, expression node, object reference and node identifier, which serves as the basis for structured localization of the normalized error event; Based on the normalized error events and the SQL structured representation, the normalized error events are mapped to the SQL structure nodes in the SQL structured representation, the database objects in the Schema context, and the dialect rules corresponding to the target SQL dialect. Based on the mapping results, an error analysis result is formed that includes the location status, affected nodes or clauses, related database objects, and candidate alternative objects or equivalent expressions. The location status is determined based on the error analysis results; when the location status is non-rewriteable, automatic SQL rewriting is stopped and handover information is output; when the location status is ambiguous, candidate replacement objects are retained and items to be clarified or a request for supplementary schema is output; when the location status is correctable, based on the number of affected nodes, the structural relationship between affected nodes, and the determination of candidate replacement objects or equivalent expressions, a correction range is determined from node replacement, clause reconstruction, or constraint regeneration, and a correction plan is formed to limit the correction target, allowed database objects, allowed correction actions, dialect restrictions, and semantic preservation constraints. Based on the correction plan, the SQL structure nodes in the SQL structured representation are added, deleted, or replaced, or at least one correction candidate is regenerated under the constraints of the correction plan, and a corresponding correction difference is generated according to the structural changes of each correction candidate relative to the SQL before correction. For each of the aforementioned correction candidates, filtering is performed based on the parsing results obtained according to the target SQL dialect, the existence of the referenced database object in the schema context, the conformity with the correction plan, and the correction differences. Priority is given to selecting correction candidates whose change range is within the scope of the correction plan, whose SQL structure remains unchanged or is equivalent in normalized representation outside the scope, and whose correction candidates do not introduce business tables, fields, or conditions that cannot be explained by the error analysis results and the correction plan as the corrected SQL. Semantic projection is extracted from the modified SQL, and the semantic projection is mapped to the preceding semantic constraints to obtain the semantic preservation check result; when the semantic preservation check result is unsuccessful, the corresponding inconsistency item is recorded, the modified SQL is rejected, and the modification plan generation process is returned to re-decision; when the semantic preservation check result is successful, the modified SQL is submitted to the target data source for re-execution. Based on the re-execution result of the corrected SQL, if the re-execution is successful, the corrected SQL and the corresponding correction record are output; if the re-execution fails, new execution failure information is obtained, and a new normalized error event is formed according to the normalization process. The new normalized error event, the correction difference, and the corresponding failure signature are added to the correction history. The subsequent path is determined according to the updated correction history, the re-execution result, and the preset termination conditions. When it is determined to continue correction, the corrected SQL is used as a new candidate SQL and enters the next round of correction based on the new execution failure information. When it is determined to request clarification, transfer processing, or terminate automatic correction, the corresponding clarification information, transfer information, or termination reason is output.

[0007] In one embodiment of the present invention, when constructing the structured execution feedback object, information related to the execution and correction of the current candidate SQL is associated with task information, execution environment information, execution failure information, schema context, prior semantic constraints, and correction history. The structured execution feedback object includes one or more of the following: task identifier, candidate SQL, SQL parameters, candidate version, data source type, target SQL dialect, connection or execution engine identifier, execution status, error code, error text, error location, tables related to the candidate SQL, fields, field types, table-field relationships, schema version, target metrics, dimensions, filtering conditions, time conditions, previous candidate SQL, executed correction actions, and corresponding execution results. Values ​​are assigned to corresponding fields based on information provided by the target data source. For information not provided by the target data source, the corresponding fields are set to empty or a status identifier is set, so that execution failure information generated by different target data sources uses a unified data structure to enter the subsequent error parsing process.

[0008] In one embodiment of the present invention, the execution failure information is normalized to obtain a normalized error event including a normalized error category, original error evidence, the object name or function name directly indicated by the error information, and the error location; for the same candidate SQL, the candidate SQL is parsed based on the target SQL dialect, and the candidate SQL is represented as at least one query clause among SELECT clause, FROM clause, JOIN clause, WHERE clause, GROUP BY clause, HAVING clause, and ORDER BY clause, and the corresponding query clause is further represented as a field reference node, function node, operation node, constant node, alias node, or type conversion node to form a structured SQL representation for locating the normalized error event.

[0009] In one embodiment of the present invention, the process of forming the error analysis result includes: Based on the error location in the normalized error event, the object name or function name appearing in the error text, and in combination with the field constraint relationship, alias scope, and query level in the SQL structured representation, determine the query clause and SQL structure node corresponding to the normalized error event; For SQL structure nodes involving database objects, the relevant database objects are further determined by combining the field types and table field dependencies in the schema context; for function or syntax nodes not involving database objects, the corresponding function or syntax expression is determined by combining the dialect rules corresponding to the target SQL dialect. Based on the current query scope of the SQL structure node, the related database object, or the function expression and syntax expression, one or more candidate alternative objects or equivalent expressions are formed according to the schema relationships in the schema context or the dialect rules, and the query clause, the SQL structure node, the related database object, and the candidate alternative objects or equivalent expressions are written into the error analysis result.

[0010] In one embodiment of the present invention, the location status is determined based on the correspondence between the normalized error event and the SQL structure node, query clause and related database object, and the location status includes correctable, ambiguous and unrewriteable. When the corresponding result can clearly identify the affected SQL structure node or query clause, and the correction range can be determined based on the existing schema context and dialect rules, the positioning status is determined to be correctable, and automatic correction is initiated based on the affected SQL structure node or query clause. When there are multiple structurally feasible but business semantically different candidate alternatives for the corresponding result, the positioning status is determined to be ambiguous, and the multiple candidate alternatives are retained for subsequent schema supplementation or generation of items to be clarified; When the corresponding result indicates that the execution failure is caused by permission, connection, data source status or other non-SQL expression reasons, the positioning status is determined to be non-rewritable, and automatic SQL rewriting is stopped based on the non-rewritable status.

[0011] In one embodiment of the present invention, the process of generating the correction plan based on the error analysis results includes: When the error analysis results indicate that the error corresponds to an expression node and there is a structurally compatible candidate replacement or equivalent expression, the expression node is identified as the correction target, and node replacement is selected as the corresponding correction range. When the error analysis results indicate that multiple interdependent affected nodes are located in the same query clause or the same query level, the query clause or query level to be adjusted is determined based on the multiple interdependent affected nodes, and clause reconstruction is selected as the corresponding correction range. When the error analysis results indicate that the error spans multiple query clauses, the original SQL structure cannot eliminate the error through local correction, or the same structural failure still occurs after local correction, the constrained regeneration is selected as the corresponding correction range based on the schema context, the target SQL dialect, and the preceding semantic constraints. When the positioning status is ambiguous, a supplementary schema or a clarification item is requested based on the retained candidate alternative objects. After obtaining information that can eliminate the ambiguity, the positioning status is redefined. When the positioning status is non-rewritable, stop SQL rewriting based on the non-rewritable status and output handover information.

[0012] In one embodiment of the present invention, after forming a plurality of correction candidates according to the correction plan, the corrected SQL to be executed is determined in the following manner: Each of the proposed correction candidates is parsed according to the target SQL dialect, and in conjunction with the schema context and the mandatory constraints of the correction plan, correction candidates that cannot be parsed according to the target SQL dialect, reference database objects that do not exist in the schema context, or violate the mandatory constraints of the correction plan are eliminated. For the remaining correction candidates after elimination, based on the difference in correction between each correction candidate and the SQL before correction, priority is given to retaining correction candidates whose SQL structures remain unchanged or are equivalent in normalized representation if the changed nodes are within the scope of the correction plan or outside the scope, and which do not introduce business tables, fields or conditions that cannot be explained by the error analysis results and the correction plan. When multiple correction candidates remain after the above processing, and there are business semantic differences among the multiple correction candidates that cannot be eliminated by existing information, a clarification item is generated based on the business semantic differences, and the submission of correction candidates with the business semantic differences is stopped until clarification information for eliminating the business semantic differences is obtained.

[0013] In one embodiment of the present invention, after obtaining the modified SQL, the semantic projection including tables, fields, aggregate expressions, grouping fields, filter fields, filter values, time fields, and time ranges is extracted from the modified SQL. The content corresponding to the target indicators, dimensions, filtering conditions and time conditions in the semantic projection is matched with the preceding semantic constraints to check whether the modified SQL retains the determined target indicators and dimensions, whether the filtering values ​​still apply to the corresponding filtering fields, and whether the time range still applies to the corresponding time fields. Based on the error analysis results and the correction plan, further check whether the corrected SQL has added business tables, fields or conditions that cannot be explained by the error analysis results and the correction plan, and determine whether the corrected SQL passes the semantic preservation check based on the above correspondence and check results.

[0014] In one embodiment of the present invention, when the re-execution of the corrected SQL fails, the failure signature is generated based on the normalized error category, the affected structure or related database object and the corresponding SQL structure fragment corresponding to this re-execution, and the failure signature is compared with the historical failure signatures recorded in the correction history. Meanwhile, the corrected SQL is normalized to obtain a normalized representation, and the normalized representation is compared with the normalized representation of historical SQL in the correction history; When the comparison result satisfies at least one of the following conditions: the corrected SQL is equivalent to the historical SQL in normalized representation; consecutive corrections produce the same failure signature and the correction difference does not form a new feasible path; the error cannot be rewritten; there is insufficient information; there is no feasible correction path; or the configured attempt budget is reached, the termination condition is determined to be met, and automatic correction is terminated accordingly.

[0015] In one embodiment of the present invention, after the normalization error event is generated, the normalization error category is determined according to the specific manifestation of the execution failure as at least one of the following: syntax or dialect error, table or field reference error, alias and qualifying error, join relationship error, data type or value error, aggregation and grouping error, and error that cannot be resolved by SQL rewriting. Based on the determined normalization error categories, affected nodes or clauses, and related database objects, a corresponding correction plan is formed. Specifically, for syntax or dialect errors, dialect equivalent expression replacement is performed under the target SQL dialect constraints; for table or field reference errors, object reference replacement is performed based on the candidate replacement objects; for alias and constraint errors, alias or query level adjustments are performed according to the alias scope and query level; for join relationship errors, join fragment reconstruction is performed based on the database objects and schema relationships on both sides of the join; for data type or value errors, type conversion or parameter format adjustment is performed based on the field types and parameter information of the relevant expressions; for aggregation and grouping errors, aggregation expressions or grouping structures are adjusted based on the correspondence between target metrics and dimensions; for errors that cannot be resolved through SQL rewriting, automatic SQL rewriting is stopped and the process is transferred to the appropriate handling procedure.

[0016] In one embodiment of the present invention, an SQL dynamic correction system based on execution feedback is also provided. The system includes an SQL receiving module, an SQL execution module, an execution feedback normalization module, an SQL structure projection module, an error location module, a correction plan module, an SQL correction module, a semantic preservation check module, and a correction flow control module. Each module works collaboratively according to the data transfer relationship between candidate SQL, structured execution feedback object, normalized error event, SQL structured representation, error analysis result, correction plan, correction difference, semantic preservation check result, and re-execution result to realize the above-mentioned SQL dynamic correction method based on execution feedback.

[0017] The present invention also provides an SQL dynamic correction system based on execution feedback, including an SQL receiving module, an SQL execution module, an execution feedback normalization module, an SQL structure projection module, an error location module, a correction plan module, an SQL correction module, a semantic preservation check module, and a correction process control module. The SQL receiving module is used to receive candidate SQL, target data source information, target SQL dialect, schema context and available upstream query semantic context. When the upstream query semantic context is not provided, it extracts the baseline semantic constraints from the candidate SQL and determines the upstream query semantic context or the baseline semantic constraints as the preceding semantic constraints. The SQL execution module is used to submit the candidate SQL to the target data source and obtain execution failure information when execution fails. The execution feedback normalization module is used to construct a structured execution feedback object based on the candidate SQL, the execution failure information, the execution environment information, the schema context, the pre-semantic constraints, and the correction history, and normalize the heterogeneous execution failure information into normalized error events; The SQL structure projection module is used to parse the candidate SQL according to the target SQL dialect to form a structured representation of SQL; The error localization module is used to map the normalized error event to the SQL structure node in the SQL structured representation, the database object in the Schema context, and the dialect rule corresponding to the target SQL dialect, so as to form an error analysis result; The correction plan module is used to determine the correction path based on the location status and affected scope in the error analysis results, and to form a correction plan when the location status is correctable. The SQL correction module is used to generate at least one correction candidate and a corresponding correction difference according to the correction plan, and to filter the correction candidate according to the target SQL dialect, schema context and correction plan to obtain the corrected SQL; The semantic preservation check module is used to extract the semantic projection of the corrected SQL, map the semantic projection to the preceding semantic constraints, and output the semantic preservation check result. The correction process control module is used to control the re-execution of the corrected SQL when the semantic preservation check result is passed, and to determine whether to output the corrected SQL, continue correction, request clarification, transfer processing, or terminate automatic correction based on the re-execution result, the correction history, and the termination condition.

[0018] The technical solution of the present invention has the following advantages compared with the prior art: The present invention discloses a dynamic SQL correction method based on execution feedback, which organizes candidate SQL, execution environment information, execution failure information, schema context, pre-semantic constraints and correction history into a structured execution feedback object, and normalizes heterogeneous execution failure information into normalized error events, so that execution failure information from different data sources can enter a unified subsequent processing flow.

[0019] This invention converts candidate SQL into a structured representation of SQL with query hierarchy, clause type, and node identifier, and locates normalized error events to specific SQL structure nodes, query clauses, and related database objects, enabling error analysis results to directly drive subsequent correction decisions.

[0020] This invention distinguishes between three positioning states: correctable, ambiguous, and non-rewriteable. This allows different errors to enter different paths, such as automatic correction, schema supplementation or clarification, or transfer for processing. This reduces the need to guess substitutes when there is insufficient evidence and to rewrite non-SQL expression errors ineffectively.

[0021] This invention limits the range of SQL changes and reduces the risk of local errors causing unconstrained changes to the entire SQL by selecting node replacement, clause reconstruction, or constrained regeneration based on the affected range, and recording the correction differences of each correction candidate relative to the original SQL.

[0022] This invention extracts the semantic projection of the modified SQL before re-execution and performs a corresponding check with the preceding semantic constraints. This enables the identification and rejection of modified results that, although grammatically valid, lack a basis for changing the target metric, dimension, filtering condition, or time condition.

[0023] This invention incorporates new normalized error events, correction differences, and failure signatures into the correction history, and terminates automatic correction when SQL normalization representations are repeated, failure signatures are repeated, correction differences do not form new feasible paths, errors are not rewriteable, or the attempt budget is reached, thus forming a correction closed loop with clear entry, loop, and exit conditions. Attached Figure Description

[0024] To make the content of this invention easier to understand, the invention will be further described in detail below with reference to specific embodiments and accompanying drawings.

[0025] Figure 1 This is the overall flowchart of the SQL dynamic correction method based on execution feedback of the present invention.

[0026] Figure 2 This is a schematic diagram of the composition and overall data flow of the SQL dynamic correction system of this invention.

[0027] Figure 3 This is a schematic diagram illustrating the structured location of errors in the present invention.

[0028] Figure 4 This is a flowchart of the hierarchical correction and correction candidate selection process of the present invention.

[0029] Figure 5 This is a flowchart of the SQL structure and semantics preservation check after the present invention.

[0030] Figure 6 This is a schematic diagram of the SQL dynamic correction state transition and termination process of the present invention. Detailed Implementation

[0031] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, so that those skilled in the art can better understand and implement the present invention. However, the embodiments described are not intended to limit the present invention.

[0032] Reference Figures 1 to 6 As shown, this embodiment provides a dynamic SQL correction method based on execution feedback. The method in this embodiment is located between the upstream candidate SQL generation stage and the subsequent query result processing stage. It receives candidate SQL generated upstream, and after the candidate SQL fails to execute, it generates a normalized error event and error analysis results, and then performs node replacement, clause reconstruction, or constraint-based regeneration. The upstream semantic enhancement Text2SQL module can provide candidate SQL, related schema fragments, and upstream query semantic context. When the upstream query semantic context is not provided, a baseline semantic constraint is extracted from the candidate SQL, and the upstream query semantic context or the baseline semantic constraint is used as a pre-defined semantic constraint. This embodiment only utilizes the pre-defined semantic constraints to limit the SQL correction process, without repeatedly executing upstream schema linking or indicator identification.

[0033] Reference Figure 2As shown, the SQL dynamic correction system includes an SQL receiving module, an SQL execution module, an execution feedback normalization module, an SQL structure projection module, an error location module, a correction plan module, an SQL correction module, a semantic preservation check module, and a correction flow control module. These modules work collaboratively according to the data transfer relationships between candidate SQL, execution failure information, structured execution feedback objects, normalized error events, SQL structured representation, error analysis results, correction plans, correction differences, semantic preservation check results, and re-execution results. Each module can be implemented by a rule component, an SQL parser, an agent, or a combination thereof, and can be deployed on the same computing device or distributed as a service.

[0034] The SQL receiving module is used to receive candidate SQL, target data source information, target SQL dialect, schema context, and available upstream query semantic context; when the upstream query semantic context is not provided, it extracts baseline semantic constraints from the candidate SQL; it determines the upstream query semantic context or the baseline semantic constraints as preconditions semantic constraints, and outputs the SQL to be executed and the task context containing the preconditions semantic constraints.

[0035] The SQL execution module is used to submit candidate SQL to the target data source based on the task context and receive the execution status; when execution fails, it obtains the error code, error text, error location and execution environment information to form execution failure information; when execution succeeds, it outputs executable SQL.

[0036] The execution feedback normalization module is used to associate candidate SQL, execution failure information, execution environment information, schema context, prior semantic constraints and correction history to construct a structured execution feedback object, and to convert heterogeneous execution failure information from different data sources into unified normalized error events, while retaining the original error evidence.

[0037] The SQL structure projection module is used to parse candidate SQL according to the target SQL dialect, forming a structured representation of SQL with query hierarchy, clause type, expression node, object reference and node identifier, which serves as the basis for structured location of normalized error events.

[0038] The error localization module is used to map normalized error events to SQL structure nodes, database objects in the schema context, and dialect rules corresponding to the target SQL dialect, to determine the affected nodes or clauses, related database objects, candidate alternatives or equivalent expressions and localization status, and output the error analysis results.

[0039] The correction plan module is used to determine the subsequent path based on the positioning status and the affected range. When the positioning status is correctable, it selects node replacement, clause reconstruction or constraint regeneration based on the number of affected nodes, the structural relationship between nodes and the determination of candidate alternatives or equivalent expressions, and outputs a structured correction plan that limits the correction target, allows the database objects to be used, allows correction actions, dialect restrictions and semantic preservation constraints.

[0040] The SQL correction module is used to perform node replacement, clause reconstruction, or constraint regeneration according to the correction plan, forming one or more correction candidates, and recording the correction differences corresponding to each correction candidate based on the changes in the SQL structure before and after the correction.

[0041] The semantic preservation check module is used to extract semantic projections from the corrected SQL, map the semantic projections to the preceding semantic constraints, and check whether the corrected SQL introduces unexplainable business semantic changes in combination with error analysis results and correction plans, so as to output semantic preservation check results.

[0042] The correction process control module is used to organize the re-execution of the corrected SQL when the semantic preservation check passes, and to determine whether to output the corrected SQL, continue correction, request clarification, transfer processing or terminate automatic correction based on the re-execution result, correction history and termination conditions, and output the final SQL or the reason for incompleteness.

[0043] After a candidate SQL query fails to execute, the execution feedback normalization module receives the execution failure information returned by the database, data access driver, or query engine, and associates it with the candidate SQL, execution environment information, schema context, pre-existing semantic constraints, and correction history corresponding to the current query task to form a structured execution feedback object. This structured execution feedback object ensures that the evidence of execution failure corresponds to the failed SQL, the target data source, and the pre-existing semantic constraints. Fields that are not provided by different data sources can be empty or represented by corresponding status identifiers; this invention does not require all implementations to use the exact same set of fields.

[0044] The task and SQL information in the structured execution feedback object can include task identifier, candidate SQL, SQL parameters, and candidate versions, which are used to identify the query object that failed to execute.

[0045] The execution environment information in the structured execution feedback object can include data source type, target SQL dialect, connection identifier, or execution engine identifier, which is used to explain database differences and limit rewritten syntax.

[0046] Error feedback information in a structured execution feedback object can include execution status, error code, error text, and the location of the error returned by the database, providing a direct basis for automatic error parsing.

[0047] The schema context in the structured execution feedback object can include tables, fields, field types, table field relationships, and schema versions related to the candidate SQL, and is used to validate error objects and replaceable objects.

[0048] The pre-constraints in the structured execution feedback object can originate from the upstream query semantic context, or they can be formed by the semantic projection of the candidate SQL when no upstream query semantic context is provided. Their content can include target metrics, dimensions, filtering conditions, time conditions, and other upstream constraints, which are used to restrict the SQL correction process from changing the original query intent without basis.

[0049] The correction history information in the structured execution feedback object can include previous candidate SQL, executed correction actions, and corresponding execution results, which are used to identify duplicate corrections and support termination judgment.

[0050] Reference Figure 3 As shown, the execution feedback normalization module first normalizes the error code, error text, and error location based on the target data source or execution engine, forming a normalized error event that includes the normalized error category, original error evidence, the object name or function name directly indicated by the error information, and the error location.

[0051] The SQL structure projection module parses candidate SQL according to the target SQL dialect, representing it as a structured object composed of query hierarchy, SELECT clause, FROM clause, JOIN clause, WHERE clause, GROUP BY clause, HAVING clause, ORDER BY clause, and expression nodes such as field references, functions, operations, and constants. It also sets identifiers for locatable nodes or fragments. The specific structured form can be an abstract syntax tree, query graph, relational operation structure, or an equivalent hierarchical structure.

[0052] The error localization module first determines the corresponding query clause and SQL structure node based on the error location in the normalized error event, the object name or function name directly appearing in the error text, and in conjunction with field constraint relationships, alias scope, and query level. For SQL structure nodes involving database objects, it further determines the relevant database objects by combining field types and table field dependencies. For function or syntax nodes that do not involve database objects, it determines the function or syntax expression by combining the dialect rules corresponding to the target SQL dialect. Subsequently, it forms one or more candidate substitute objects or equivalent expressions based on the schema relationships or dialect rules in the current query scope. For example, for a non-existent field, it first locates the corresponding field reference and its clause in the SQL structure, and then forms candidate substitute fields based on the table, alias, and schema relationships involved in the clause; for functions or syntax that are not supported, it locates the corresponding function or syntax node and obtains the equivalent expression allowed by the target SQL dialect; for type incompatibility, it locates the expressions on both sides involved in the comparison, calculation, or join and their type information.

[0053] The error localization module generates structured error analysis results based on the corresponding results mentioned above. These results may include normalized error categories, original error evidence, affected structures, related database objects, candidate replacement objects or equivalent expressions, localization status, suggested correction scope, and semantic preservation constraints. Affected structures may include query level, clause type, node identifier, and corresponding SQL fragments; related database objects may include tables, fields, functions, aliases, parameters, and their schema relationships; candidate replacement objects may be one or more database objects available within the current schema and query scope; and equivalent expressions may be function expressions or syntactic expressions compatible with the target SQL dialect.

[0054] When error evidence clearly identifies the affected SQL structure node or query clause, and the scope of correction can be determined based on the existing schema context and dialect rules, the location status is marked as correctable. When multiple structurally feasible but semantically different candidate alternatives exist, the location status is marked as ambiguous, and the candidate alternatives are retained. When the failure stems from permissions, connection, data source status, or other non-SQL expression reasons, the location status is marked as non-rewriteable. This process does not require setting fixed confidence levels, weights, or thresholds.

[0055] For grammatical or dialectal errors, the execution feedback may manifest as a grammatical error, an unsupported function or pagination, or an incompatible date expression. Automatic parsing is used to locate incompatible grammatical nodes, functions, or expressions, and then equivalent expressions supported by the target dialect are used.

[0056] For table or field reference errors, the execution feedback may be that the table does not exist, the field does not exist, or the object name cannot be resolved. Automatic resolution is used to locate the object reference position and match it with the Schema candidate object. Subsequent execution will replace the object or supplement the limiting information.

[0057] For alias and qualification errors, the execution feedback may be that the alias does not exist, the field reference is ambiguous, or the scope is incorrect. Automatic resolution is used to locate the alias definition, reference position, and the query level to which it belongs, and then the alias, field qualification, or query level can be adjusted.

[0058] For join relationship errors, the execution feedback may manifest as a missing join field, incompatible types on both sides of the join, or an incorrect join expression reference. The system automatically parses the data to locate the objects on both sides of the join and the relationship between related table fields, and then reconstructs the join field or join fragment.

[0059] For data type or value errors, the execution feedback may manifest as type conversion failure, parameter format error, or comparison type incompatibility. Automatic parsing is used to locate the fields and parameters involved in the conversion, comparison, or calculation, and subsequent adjustments are made to the type conversion, parameter format, or expression.

[0060] For aggregation and grouping errors, the execution feedback may manifest as non-aggregate fields not being grouped or aggregate functions not being used. The system will automatically parse the data to locate the relationship between the selected items, aggregate items, and grouping items, and then adjust the aggregation expression or grouping structure accordingly.

[0061] For errors that cannot be resolved by SQL rewriting, such as permission denial, connection failure, or data source unavailability, automatic parsing is used to identify that the failure is not due to an error in the SQL expression. Subsequently, automatic rewriting is stopped and the relevant process is transferred.

[0062] Reference Figure 4 As shown, the correction plan module formulates subsequent processing decisions based on the positioning status, the number of affected nodes, the structural relationships between affected nodes, and the determination of candidate replacement objects or equivalent expressions. For non-rewriteable states, SQL correction is stopped and the corresponding process is transferred; for ambiguous states, candidate replacement objects are retained and relevant schemas are requested to be supplemented or items to be clarified are generated; for correctable states, node replacement, clause reconstruction, or constraint-based regeneration is selected according to the affected scope, and a correction plan is formed. The correction plan at least defines the target node or clause, the allowed database objects, the target SQL dialect, the allowed correction actions, and the semantic preservation constraints determined by the preceding semantic constraints.

[0063] When an error corresponds to an expression node and a structurally compatible alternative or equivalent expression exists, node replacement is performed, maintaining the SQL structure outside the scope of the correction plan unchanged or equivalent in normalized representation. When multiple dependent nodes are located in the same query clause or the same query level, the query clause or query level is reconstructed by adding, deleting, or replacing nodes. When an error spans multiple query clauses, the original SQL structure cannot eliminate the error through local correction, or the same structural failure still occurs after local correction, the complete SQL is regenerated under the schema context, target SQL dialect, and pre-existing semantic constraints. Correction actions can be represented as adding, deleting, or replacing SQL structure nodes, and the nodes or clauses that change and remain unchanged are recorded to form correction differences.

[0064] SQL correction can be achieved through rule templates, abstract syntax tree transformations, agent generation, or a combination thereof. For object references, dialect functions, or type conversions that can be uniquely located and have definite alternatives, structural node transformations are preferred. For query clauses or complete SQL that require reconstruction, the generation component can generate candidate results based on the correction plan. This invention does not limit specific models, scoring formulas, or replacement dictionaries; the focus is on the structured transmission relationship between error analysis results, correction plans, and correction differences.

[0065] When the SQL correction module generates multiple correction candidates, it first parses each candidate according to the target SQL dialect, eliminating candidates that cannot be parsed, reference database objects not existing in the schema context, or violate the mandatory constraints of the correction plan. Then, it compares the correction differences between the candidates, prioritizing those whose changed nodes are within the scope of the correction plan, whose SQL structures remain unchanged or are equivalent in normalized representation, and which do not introduce business tables, fields, or conditions that cannot be explained by error analysis results and the correction plan. If multiple candidates still exist and there are no business semantic differences between them, a queue of candidates to be executed can be formed according to a preset stable order, and processed sequentially based on subsequent execution feedback. If there are business semantic differences between candidates that cannot be eliminated by existing information, a clarification item is generated, and the submission of candidates with such business semantic differences for execution is stopped until the corresponding clarification information is obtained.

[0066] If the modified SQL does not meet the target dialect structure check or semantic preservation constraint, the modified SQL is rejected, the target data source is not submitted for execution, and the process is returned to the modification plan module for re-decision.

[0067] Reference Figure 5As shown, after the SQL correction module outputs the corrected SQL and the correction differences, it first parses the corrected SQL according to the target SQL dialect. If a valid structured representation of SQL cannot be formed, the correction result is rejected. If parsing is possible, semantic projections of tables, fields, aggregate expressions, grouping fields, filter fields and filter values, time fields and time ranges are extracted from the corrected SQL, and these semantic projections are mapped to pre-existing semantic constraints. The pre-existing semantic constraints can be provided by the upstream query semantic context; if no upstream query semantic context is provided, a baseline semantic constraint can be formed from the semantic projection of the original SQL, and this baseline semantic constraint is used as the pre-existing semantic constraint.

[0068] The semantic preservation check at least determines: whether the corrected SQL still achieves the target metrics and dimensions defined in the pre-existing semantic constraints, whether the filter values ​​still apply to the corresponding filter fields, whether the time range still applies to the corresponding time fields, and whether any business tables, fields, or conditions have been added that cannot be explained by the error analysis results and the correction plan. If the check passes, the corrected SQL is re-executed; if the check fails, the inconsistency is recorded, the corrected SQL is rejected, and the process returns to the correction plan module for further decision-making. This check is used to verify the preservation of pre-existing semantic constraints during the correction process and does not replace result credibility verification or metric caliber verification.

[0069] Reference Figure 1 As shown, the method in this embodiment includes the following steps: S1: Receive candidate SQL and obtain target data source information, target SQL dialect, schema context and available upstream query semantic context; when the upstream query semantic context is not provided, extract baseline semantic constraints from candidate SQL; determine the upstream query semantic context or the baseline semantic constraints as preconditions and form a task context.

[0070] S2: Submit candidate SQL to the target data source based on the task context; if the execution is successful, output the candidate SQL as executable SQL and end the current correction process; if the execution fails, obtain the error code, error text, error location and execution environment information, and form execution failure information.

[0071] S3: Constructs a structured execution feedback object based on candidate SQL, execution failure information, execution environment information, schema context, pre-semantic constraints, and correction history, and normalizes heterogeneous execution failure information into normalized error events.

[0072] S4: Parse candidate SQL according to the target SQL dialect to form a structured representation of SQL that includes query level, clause type, expression node, object reference and node identifier.

[0073] S5: Map normalized error events to SQL structure nodes, database objects in the schema context, and dialect rules corresponding to the target SQL dialect to form error analysis results that include location status, affected nodes or clauses, related database objects, and candidate alternatives or equivalent expressions.

[0074] S6: Determine the location status based on the error analysis results; when the location status is non-rewriteable, stop automatic SQL rewriting and output handover information; when the location status is ambiguous, retain candidate replacement objects and output items to be clarified or request supplementary schema; when the location status is correctable, proceed to generate a correction plan.

[0075] S7: For error analysis results with a correctable positioning status, based on the number of affected nodes, the structural relationship between affected nodes, and the determination of candidate replacement objects or equivalent expressions, select node replacement, clause reconstruction, or constrained regeneration, and form a correction plan that includes correction targets, allowed database objects, allowed correction actions, dialect restrictions, and semantic preservation constraints.

[0076] S8: Perform addition, deletion or replacement of SQL structure nodes according to the correction plan, or regenerate one or more correction candidates under the constraints of the correction plan, and form corresponding correction differences based on the structural changes of each correction candidate relative to the SQL before correction.

[0077] S9: Filter correction candidates based on the target SQL dialect parsing results, the existence of the referenced database objects in the schema context, and the compliance of the correction plan; prioritize retaining candidates whose changes fall within the scope of the correction plan, whose SQL structures remain unchanged or are equivalent in normalized representation, and whose changes do not introduce business tables, fields, or conditions that cannot be explained by the error analysis results and the correction plan, and determine them as the corrected SQL.

[0078] S10: Extract semantic projection from the corrected SQL and map the semantic projection to the preceding semantic constraints; if the check fails, record the inconsistency, reject the current correction, and return to the correction plan generation process for re-decision; if the check passes, submit the corrected SQL to the target data source for re-execution.

[0079] S11: When re-execution fails, new execution failure information is obtained and a new normalized error event is formed. The new normalized error event, the correction difference, and the failure signature are added to the correction history. The failure signature is determined by at least the normalized error category, the affected structure or related database object, and the corresponding SQL structure fragment.

[0080] S12: If re-execution is successful, output the corrected SQL and the corresponding correction record; if re-execution fails and the termination condition is not met, use the corrected SQL as a new candidate SQL and enter the next round of correction based on the new execution failure information; when there is duplicate equivalent SQL, duplicate identical failure signatures and the correction difference does not form a new feasible path, the error cannot be rewritten, the information is insufficient, there is no feasible correction path or the configured attempt budget is reached, output the information to be clarified, the transfer information or the termination reason and end the current correction process.

[0081] Reference Figure 6 As shown, the correction process control module determines the current task status based on error analysis results, semantic preservation check results, correction history, and re-execution results, so that each status—correction success, continue correction, correction rejection, need for clarification, transfer for processing, and termination—has clear entry conditions and subsequent actions, avoiding the conversion of all execution failures into new SQL rewrite requests.

[0082] When the corrected SQL passes the check and is successfully executed in the target data source, the processing status is "correction successful," and the SQL and the corrected record are output.

[0083] If the execution fails again, but the error analysis result is different from the correction history and the location status is correctable, and the termination condition is not met, the processing status is to continue correction. The new normalized error event, correction difference and failure signature are added to the correction history, and the corrected SQL is used as a new candidate SQL to enter the next round of correction.

[0084] If the corrected SQL fails the dialect structure check or semantic preservation check, the processing status is "correction rejected," the SQL is not executed, and the process returns to the correction plan module.

[0085] When there are multiple structurally feasible but business-semantic candidate alternatives, or when the schema information required to determine the scope of correction is lacking, the processing status is "clarification required". The candidate alternatives and the content to be clarified are output, and the error location or correction plan generation process is re-entered after obtaining information that can eliminate ambiguity.

[0086] When a failure is caused by permission, connection, data source status, or other non-SQL expression reasons, the processing status is transferred to handling, automatic rewriting is stopped, and the corresponding process is transferred.

[0087] When the corrected SQL is equivalent to the historical SQL in normalized representation, consecutive corrections produce the same failure signature, and the correction differences do not form a new feasible path, there is no feasible correction path, or the configured attempt budget is reached, the processing status is terminated, and the incomplete reason and error analysis record are output.

[0088] To identify invalid loops, the SQL statements before and after correction can be normalized, and a failure signature can be generated based on the normalization error category, the affected structure or related database object, and the corresponding SQL structure fragment. Automatic correction can be terminated when the corrected SQL is equivalent to the historical SQL in normalization representation, or when consecutive corrections produce the same failure signature and the correction differences do not form a new feasible path. The trial budget and specific normalization and comparison methods can be configured according to the application environment; this invention does not limit the fixed number of retries, scoring threshold, hash algorithm, or confidence formula.

[0089] In an example of correcting a grammatical or database dialect error, the candidate SQL contains a date function that the target database does not support. The execution feedback normalization module generates a normalized error event based on the function name and error location in the error text. The error location module locates the normalized error event to the function node in the WHERE clause and determines the usable equivalent expression based on the dialect rules corresponding to the target SQL dialect, thus determining the location status as correctable. The correction plan limits replacement to only the function node and determines the original time field and time range in the pre-semantic constraints as semantic preservation constraints. The SQL correction module replaces the function node with an equivalent expression supported by the target SQL dialect, and the correction difference record records this replacement action. The system re-extracts the time semantics of the corrected SQL, and after confirming that the time field and time range have not changed, submits the corrected SQL for re-execution.

[0090] In a correction example of a table or field reference error, the execution feedback indicates that a certain field does not exist. After the execution feedback normalization module generates a normalized error event, the error localization module locates it to the field reference node in the SELECT clause based on the field name and error location. Then, it generates candidate replacement fields based on the table alias scope of that node and the field relationships in the schema table. When a candidate replacement field can be uniquely identified and corresponds to the dimension in the preceding semantic constraints, the localization status is determined to be correctable and node replacement is adopted. When multiple fields are structurally usable but have different business meanings, the localization status is determined to be ambiguous, and the system outputs candidate fields and their respective tables to form items to be clarified. No field is automatically selected until clarification information is obtained.

[0091] In an example of correcting aggregation and grouping errors, the candidate SQL fails to execute due to inconsistencies between the select and grouping terms. The error localization module locates the normalized error event to the relevant nodes in the SELECT and GROUP BY clauses, determining that single-node replacement is insufficient to eliminate the error, and therefore refactors the select clauses. The correction plan uses the target metrics and analysis dimensions already defined in the preceding semantic constraints as semantic preservation constraints, limiting the select, aggregation, and grouping terms that can be adjusted. After the SQL correction module generates the corrected SQL, the semantic preservation check module compares the metric expressions, dimension fields, and grouping fields respectively; after the check passes, the correction flow control module submits the corrected SQL to the target data source for re-execution.

[0092] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0093] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0094] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0095] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0096] Finally, it should be noted that the above specific embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to examples, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for dynamic SQL correction based on execution feedback, characterized in that, include: Receive candidate SQL statements and obtain the target data source information, target SQL dialect, schema context, and available upstream query semantic context corresponding to the candidate SQL statements; when the upstream query semantic context is not provided, extract baseline semantic constraints from the candidate SQL statements; determine the upstream query semantic context or the baseline semantic constraints as preconditions semantic constraints, and form a task context based on the candidate SQL statements, the target data source information, the target SQL dialect, the schema context, and the preconditions semantic constraints. Based on the task context, the candidate SQL is submitted to the target data source; when the execution is successful, the candidate SQL is output as executable SQL and the current correction process ends. When execution fails, obtain the error code, error text, error location, and execution environment information corresponding to this execution, and generate execution failure information accordingly; Based on the candidate SQL, the execution failure information, the execution environment information, the schema context, the pre-semantic constraints, and the correction history, a structured execution feedback object is constructed, and the heterogeneous execution failure information in the structured execution feedback object is normalized to obtain normalized error events. The candidate SQL is parsed according to the target SQL dialect to form a structured representation of SQL that includes query level, clause type, expression node, object reference and node identifier, which serves as the basis for structured localization of the normalized error event; Based on the normalized error events and the SQL structured representation, the normalized error events are mapped to the SQL structure nodes in the SQL structured representation, the database objects in the Schema context, and the dialect rules corresponding to the target SQL dialect. Based on the mapping results, an error analysis result is formed that includes the location status, affected nodes or clauses, related database objects, and candidate alternative objects or equivalent expressions. The location status is determined based on the error analysis results; when the location status is non-rewriteable, the automatic SQL rewriting is stopped and the handover information is output. When the positioning status is ambiguous, retain the candidate alternative and output the item to be clarified or request supplementary schema; When the positioning state is correctable, based on the number of affected nodes, the structural relationship between affected nodes, and the determination of candidate replacement objects or equivalent expressions, a correction range is determined among node replacement, clause reconstruction, or constrained regeneration, and a correction plan is formed to limit the correction target, the database objects that can be used, the correction actions that can be allowed, dialect restrictions, and semantic preservation constraints. Based on the correction plan, the SQL structure nodes in the SQL structured representation are added, deleted, or replaced, or at least one correction candidate is regenerated under the constraints of the correction plan, and a corresponding correction difference is generated according to the structural changes of each correction candidate relative to the SQL before correction. For each of the aforementioned correction candidates, filtering is performed based on the parsing results obtained according to the target SQL dialect, the existence of the referenced database object in the schema context, the conformity with the correction plan, and the correction differences. Priority is given to selecting correction candidates whose change range is within the scope of the correction plan, whose SQL structure remains unchanged or is equivalent in normalized representation outside the scope, and whose correction candidates do not introduce business tables, fields, or conditions that cannot be explained by the error analysis results and the correction plan as the corrected SQL. Semantic projections are extracted from the revised SQL and mapped to the preceding semantic constraints to obtain semantic preservation check results. When the semantic preservation check result fails, the corresponding inconsistency item is recorded, the revised SQL is rejected, and the process is returned to the revision plan generation process for re-decision. When the semantic preservation check passes, the corrected SQL is submitted to the target data source for re-execution; Based on the result of re-execution of the corrected SQL, the corrected SQL and the corresponding correction record are output when the re-execution is successful; When re-execution fails, new execution failure information is obtained, and a new normalized error event is formed according to the normalization process. The new normalized error event, the correction difference, and the corresponding failure signature are added to the correction history. The subsequent path is determined based on the updated correction history, the re-execution result, and the preset termination conditions. When it is determined to continue correction, the corrected SQL is used as a new candidate SQL and enters the next round of correction based on the new execution failure information. When it is determined to request clarification, transfer processing, or terminate automatic correction, the corresponding clarification information, transfer information, or termination reason is output.

2. The SQL dynamic correction method based on execution feedback according to claim 1, characterized in that, When constructing the structured execution feedback object, information related to the execution and correction of the current candidate SQL is associated with task information, execution environment information, execution failure information, schema context, prior semantic constraints, and correction history. The structured execution feedback object includes one or more of the following: task identifier, candidate SQL, SQL parameters, candidate version, data source type, target SQL dialect, connection or execution engine identifier, execution status, error code, error text, error location, tables related to the candidate SQL, fields, field types, table-field relationships, schema version, target metrics, dimensions, filtering conditions, time conditions, previous candidate SQL, executed correction actions, and corresponding execution results. Values ​​are assigned to corresponding fields based on information provided by the target data source. For information not provided by the target data source, the corresponding fields are set to null or a status indicator is set, ensuring that execution failure information from different target data sources uses a unified data structure for subsequent error parsing.

3. The SQL dynamic correction method based on execution feedback according to claim 1, characterized in that, The execution failure information is normalized to obtain the normalized error event, which includes the normalized error category, the original error evidence, the object name or function name directly indicated by the error information, and the error location. For the same candidate SQL, the candidate SQL is parsed based on the target SQL dialect, and the candidate SQL is represented as at least one query clause among SELECT clause, FROM clause, JOIN clause, WHERE clause, GROUP BY clause, HAVING clause, and ORDER BY clause. The corresponding query clause is further represented as field reference node, function node, operation node, constant node, alias node, or type conversion node to form a structured SQL representation for locating the normalized error event.

4. The SQL dynamic correction method based on execution feedback according to claim 1, characterized in that, The process of generating the error analysis results includes: Based on the error location in the normalized error event, the object name or function name appearing in the error text, and in combination with the field constraint relationship, alias scope, and query level in the SQL structured representation, determine the query clause and SQL structure node corresponding to the normalized error event; For SQL structure nodes involving database objects, the relevant database objects are further determined by combining the field types and table field dependencies in the schema context; for function or syntax nodes not involving database objects, the corresponding function or syntax expression is determined by combining the dialect rules corresponding to the target SQL dialect. Based on the current query scope of the SQL structure node, the related database object, or the function expression and syntax expression, one or more candidate alternative objects or equivalent expressions are formed according to the schema relationships in the schema context or the dialect rules, and the query clause, the SQL structure node, the related database object, and the candidate alternative objects or equivalent expressions are written into the error analysis result.

5. The SQL dynamic correction method based on execution feedback according to claim 1, characterized in that, The location status is determined based on the correspondence between the normalized error event and the SQL structure node, query clause and related database object. The location status includes correctable, ambiguous and non-rewriteable. When the corresponding result can clearly identify the affected SQL structure node or query clause, and the correction range can be determined based on the existing schema context and dialect rules, the positioning status is determined to be correctable, and automatic correction is initiated based on the affected SQL structure node or query clause. When there are multiple structurally feasible but business semantically different candidate alternatives for the corresponding result, the positioning status is determined to be ambiguous, and the multiple candidate alternatives are retained for subsequent schema supplementation or generation of items to be clarified; When the corresponding result indicates that the execution failure is caused by permission, connection, data source status or other non-SQL expression reasons, the positioning status is determined to be non-rewritable, and automatic SQL rewriting is stopped based on the non-rewritable status.

6. The SQL dynamic correction method based on execution feedback according to claim 1, characterized in that, The process of generating the correction plan based on the error analysis results includes: When the error analysis results indicate that the error corresponds to an expression node and there is a structurally compatible candidate replacement or equivalent expression, the expression node is identified as the correction target, and node replacement is selected as the corresponding correction range. When the error analysis results indicate that multiple interdependent affected nodes are located in the same query clause or the same query level, the query clause or query level to be adjusted is determined based on the multiple interdependent affected nodes, and clause reconstruction is selected as the corresponding correction range. When the error analysis results indicate that the error spans multiple query clauses, the original SQL structure cannot eliminate the error through local correction, or the same structural failure still occurs after local correction, the constrained regeneration is selected as the corresponding correction range based on the schema context, the target SQL dialect, and the preceding semantic constraints. When the positioning status is ambiguous, a supplementary schema or a clarification item is requested based on the retained candidate alternative objects. After obtaining information that can eliminate the ambiguity, the positioning status is redefined. When the positioning status is non-rewritable, stop SQL rewriting based on the non-rewritable status and output handover information.

7. The SQL dynamic correction method based on execution feedback according to claim 1, characterized in that, After generating multiple revision candidates based on the revision plan, the revised SQL to be executed is determined as follows: Each of the proposed correction candidates is parsed according to the target SQL dialect, and in conjunction with the schema context and the mandatory constraints of the correction plan, correction candidates that cannot be parsed according to the target SQL dialect, reference database objects that do not exist in the schema context, or violate the mandatory constraints of the correction plan are eliminated. For the remaining correction candidates after elimination, based on the difference in correction between each correction candidate and the SQL before correction, priority is given to retaining correction candidates whose SQL structures remain unchanged or are equivalent in normalized representation if the changed nodes are within the scope of the correction plan or outside the scope, and which do not introduce business tables, fields or conditions that cannot be explained by the error analysis results and the correction plan. When multiple correction candidates remain after the above processing, and there are business semantic differences among the multiple correction candidates that cannot be eliminated by existing information, a clarification item is generated based on the business semantic differences, and the submission of correction candidates with the business semantic differences is stopped until clarification information for eliminating the business semantic differences is obtained.

8. The SQL dynamic correction method based on execution feedback according to claim 1, characterized in that, After obtaining the revised SQL, extract the semantic projection from the revised SQL, including tables, fields, aggregate expressions, grouping fields, filter fields, filter values, time fields, and time ranges; The content corresponding to the target indicators, dimensions, filtering conditions and time conditions in the semantic projection is matched with the preceding semantic constraints to check whether the modified SQL retains the determined target indicators and dimensions, whether the filtering values ​​still apply to the corresponding filtering fields, and whether the time range still applies to the corresponding time fields. Based on the error analysis results and the correction plan, further check whether the corrected SQL has added business tables, fields or conditions that cannot be explained by the error analysis results and the correction plan, and determine whether the corrected SQL passes the semantic preservation check based on the above correspondence and check results.

9. The SQL dynamic correction method based on execution feedback according to claim 1, characterized in that, When the re-execution of the corrected SQL fails, the failure signature is generated based on the normalized error category, affected structure or related database object and corresponding SQL structure fragment corresponding to this re-execution, and the failure signature is compared with the historical failure signature recorded in the correction history. Meanwhile, the corrected SQL is normalized to obtain a normalized representation, and the normalized representation is compared with the normalized representation of historical SQL in the correction history; When the comparison result satisfies at least one of the following conditions: the corrected SQL is equivalent to the historical SQL in normalized representation; consecutive corrections produce the same failure signature and the correction difference does not form a new feasible path; the error cannot be rewritten; there is insufficient information; there is no feasible correction path; or the configured attempt budget is reached, the termination condition is determined to be met, and automatic correction is terminated accordingly.

10. The SQL dynamic correction method based on execution feedback according to claim 1, characterized in that, After the normalized error event is generated, the normalized error category is determined according to the specific manifestation of the execution failure as at least one of the following: syntax or dialect error, table or field reference error, alias and qualification error, join relationship error, data type or value error, aggregation and grouping error, and error that cannot be resolved by SQL rewriting; Based on the determined normalization error categories, the affected nodes or clauses, and the relevant database objects, a corresponding correction plan is formed. Specifically, for syntax or dialect errors, dialect equivalent expression replacement is performed under the target SQL dialect constraints; for table or field reference errors, object reference replacement is performed based on the candidate replacement objects; for alias and constraint errors, alias or query level adjustments are performed according to the alias scope and query level; for join relationship errors, join fragment reconstruction is performed based on the database objects and schema relationships on both sides of the join; and for data type or value errors, type conversion or parameter format adjustments are performed based on the field types and parameter information of the relevant expressions. For aggregation and grouping errors, execute aggregation expressions or adjust grouping structures based on the correspondence between target metrics and dimensions; for errors that cannot be resolved by SQL rewriting, stop automatic SQL rewriting and transfer the case to the appropriate processing flow.

Images