Cross-database dialect intelligent ddl conversion method based on g4 formal grammar comparison

Abstract

This application discloses a cross-database dialect intelligent DDL conversion method based on G4 formal grammar comparison. This method uses ANTLR4 G4 formal grammar files as the semantic benchmark and establishes a precise grammatical mapping relationship between the source and target databases through four steps: grammar rule alignment, grammar element mapping, grammar difference marking, and conversion rule generation. Based on a unified AST model, the parsing and generation processes are decoupled. A cross-dialect standardized segment model is constructed through the parsing visitor, and then the target SQL is generated node by node by the translation visitor. It supports three configurable conversion strategies: strict, lenient, and warning, as well as real-time incremental DDL synchronization. This invention has advantages such as high conversion accuracy, comprehensive dialect coverage, low expansion cost, flexible and configurable strategies, and zero intrusion into business systems. It is adaptable to bidirectional DDL conversion of various mainstream databases such as Oracle, MySQL, and OpenGauss.

Description

Technical Field

[0001] This application relates to the field of database dialect conversion technology, specifically to a cross-database dialect intelligent DDL conversion method, apparatus, computer-readable storage medium, and electronic device based on G4 formal grammar comparison. Background Technology

[0002] In enterprise-level database cross-database, heterogeneous migration, and incremental synchronization scenarios, cross-dialect conversion of DDL (Data Definition Language) is a core technical challenge. Because different database vendors use differentiated SQL syntax and data type systems, the expression of the same DDL semantics varies significantly across different databases.

[0003] Existing technologies mainly fall into the following three categories of implementation methods:

[0004] (1) String template-based conversion scheme

[0005] This scheme uses predefined regular expressions or string templates to perform pattern matching and replacement on the source DDL statement. However, it can only convert a small number of common grammatical structures. Once it encounters complex grammars unique to dialects, such as partitioning syntax, constraint definitions, stored parameters, or encrypted columns, the matching patterns become ineffective, resulting in low accuracy and poor maintainability.

[0006] (2) Manual mapping scheme based on intermediate representation

[0007] This approach manually translates the source DDL into the target DDL line by line by creating data type and syntax rule lookup tables. However, it heavily relies on the continuous maintenance of numerous manual rules, has limited coverage, requires significant investment in rule refinement when adding new database dialects or syntax versions, and suffers from poor scalability.

[0008] (3) Structural migration scheme based on schema metadata

[0009] This solution reconstructs the table structure in the target database by reading metadata information from the database system tables. It can only handle objects that already exist in the database, cannot handle SQL text-level DDL transformations, and cannot support incremental DDL synchronization scenarios.

[0010] The shortcomings of existing technologies are mainly reflected in the following aspects: string / regular expression-based conversion schemes cannot handle differences at the grammatical structure level, resulting in low accuracy and high omission rate; manual mapping schemes have high maintenance costs, incomplete dialect coverage, and long cycles for adding new dialects; metadata migration schemes cannot handle SQL text input and do not support incremental DDL synchronization; all schemes lack the ability to formally model and systematically compare multi-dialect grammatical rules; and conversion strategies are not configurable, failing to adapt to the differentiated needs of different business scenarios for conversion accuracy and compatibility. Summary of the Invention

[0011] To overcome the shortcomings of existing technologies, such as low DDL conversion accuracy, incomplete dialect coverage, high expansion costs, lack of formal benchmarks for grammatical comparison, and non-configurable conversion strategies, this application proposes a new intelligent cross-database dialect DDL conversion method based on G4 formal grammatical comparison.

[0012] This invention aims to achieve the following objectives:

[0013] (1) Using the ANTLR4 G4 formal grammar file as the semantic benchmark, establish a precise grammar mapping relationship between the source and target databases;

[0014] (2) By using the unified abstract syntax tree (AST) as an intermediate representation, the parsing and generation processes are decoupled, enabling the rapid construction of conversion channels between any dialects;

[0015] (3) Supports bidirectional DDL conversion for more than 10 mainstream and domestic database dialects, covering more than 15 DDL operation types;

[0016] (4) Provides multi-level configurable conversion strategies to adapt to different business needs, from strict consistency to relaxed compatibility;

[0017] (5) Adding a new database dialect only requires writing the corresponding G4 syntax file and Visitor implementation; the core model does not need any modification.

[0018] To achieve the above objectives, this application provides the following technical solution:

[0019] The first aspect of this application provides a cross-database dialect intelligent DDL conversion method based on G4 formal grammar comparison, such as... Figure 1 As shown, the method includes the following steps:

[0020] S1. Syntax Selection and Parsing: Receives source DDL (Data Definition Language) text input, source database type, and target database type; loads the corresponding ANTLR4 G4 syntax file according to the source database type; performs lexical analysis and syntax analysis on the source DDL text in sequence; and generates a source syntax parse tree (ParseTree).

[0021] S2. Unified AST Construction: By traversing the ParseTree through the parser Visitor, the parent-child relationship between nodes is automatically maintained based on annotation and reflection mechanisms to construct a unified abstract syntax tree (AST) model across dialects; the parser Visitor implements an independent Visitor class for each database dialect, which is used to map dialect-related syntax nodes to standard Segment objects.

[0022] S3. Syntax Comparison and Mapping: Compare the G4 grammar production rules of the source database and the target database, identify the corresponding grammar nodes and establish grammar element mapping relationships, automatically mark the difference nodes of dialect-specific grammar structures, and generate a three-level transformation rule system containing AST rules, string rules and mapping rules.

[0023] S4. Target SQL Generation: By traversing the Unified Abstract Syntax Tree (AST) model through the Visitor translation, the visit() method corresponding to the DDL statement type is called to generate the target dialect SQL node by node, and then processed by the transformation strategy engine to output the target DDL text.

[0024] Furthermore, in the method of this application, the ANTLR4 G4 grammar file described in step S1 defines the complete grammatical production rules of the database dialect in Extended Backus Normal Form (EBNF), and is organized in a monolithic or modular mode. The modular mode is split into multiple import files according to the dimensions of DDL, DML, DAL, DCL, TCL, keywords, and literals. The lexical analysis and grammatical analysis are implemented based on ANTLR4.

[0025] Furthermore, in the method of this application, the standard Segment object described in step S2 is organized according to semantic dimensions, covering column definitions, table definitions, partitions, indexes, expressions, functions, data types, views, sequences, constraints, tablespaces, and database dimensions.

[0026] Furthermore, in the method of this application, the syntax comparison and mapping in step S3 includes:

[0027] S31. Syntax rule benchmarking: Analyze the DDL-related production rules in source G4 and target G4, identify the corresponding syntax production nodes and establish a preliminary benchmarking relationship;

[0028] S32. Syntax element mapping: By comparing the syntactic elements on the right side of the production rule, a precise correspondence between the source dialect and the target dialect is established.

[0029] S33, Syntactic Difference Marking: Automatically identifies grammatical structures unique to each dialect and marks them as difference nodes that require specific processing;

[0030] S34. Transformation rule generation: Generate corresponding transformation strategies for the difference nodes and load them into the transformation pipeline as needed.

[0031] Furthermore, in the method of this application, the AST rule in step S3 is used to handle syntactic structural differences, the string rule is used to handle text-level differences, and the mapping rule is used to handle semantic mapping.

[0032] Furthermore, in the method of this application, in step S3, cross-dialect data type mapping is performed through a data type converter factory, wherein the data type converter factory has built-in multiple sets of data type mapping relationships between database dialects.

[0033] Furthermore, in the method of this application, the translation Visitor in step S4 generates the target DDL text through a conversion strategy engine. The conversion strategy engine supports three conversion strategies: strict mode, lenient mode, and warning mode. When mapping fails in strict mode, an error is reported. When mapping fails in lenient mode, it is downgraded to a compatible alternative. When mapping fails in warning mode, a log is recorded and execution continues.

[0034] Furthermore, the method of this application supports incremental DDL transformations, wherein the incremental DDL includes ALTER TABLE RENAME, CREATE TABLE LIKE, and ALTER TABLE ADD / DROP / MODIFY COLUMN operation types.

[0035] Furthermore, in the method of this application, the source database type and the target database type are selected from any one of Oracle, MySQL, SQL Server, PostgreSQL, and OpenGauss, and the source database type and the target database type are different;

[0036] The method takes plain SQL text as input and output and does not depend on the connection to the source or target database.

[0037] The second aspect of this application provides a cross-database dialect intelligent DDL conversion device based on G4 formal grammar comparison. When the device operates, it implements the steps of the aforementioned cross-database dialect intelligent DDL conversion method based on G4 formal grammar comparison, such as... Figure 2 As shown, the device includes:

[0038] The syntax selection and parsing module is used to receive the source DDL text input and the source database type and target database type; load the corresponding ANTLR4 G4 syntax file according to the source database type; perform lexical analysis and syntax analysis on the source DDL text in sequence; and generate the source syntax parse tree (ParseTree).

[0039] A unified AST construction module is used to traverse the ParseTree by parsing the Visitor, automatically maintain the parent-child relationship between nodes based on annotation and reflection mechanisms, and construct a cross-dialect unified abstract syntax tree (AST) model; the parsing Visitor implements an independent Visitor class for each database dialect, which is used to map dialect-related syntax nodes to standard Segment objects.

[0040] The grammar comparison and mapping module is used to compare the G4 grammar production rules of the source database and the target database, identify the corresponding grammar nodes and establish grammar element mapping relationships, automatically mark the difference nodes of dialect-specific grammar structures, and generate a three-level transformation rule system containing AST rules, string rules and mapping rules.

[0041] The target SQL generation module is used to traverse the Unified Abstract Syntax Tree (AST) model by translating the Visitor, call the visit() method corresponding to the DDL statement type to generate target dialect SQL node by node, and process it through the transformation strategy engine to output the target DDL text.

[0042] A third aspect of this application provides an electronic device, including: a memory and a processor;

[0043] Memory: Used to store computer programs;

[0044] Processor: Used to execute the computer program to implement the steps of the aforementioned cross-database dialect intelligent DDL conversion method based on G4 formal grammar comparison.

[0045] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the aforementioned cross-database dialect intelligent DDL conversion method based on G4 formal grammar comparison.

[0046] In summary, compared with the prior art, the present invention has the following advantages:

[0047] (1) Conversion accuracy has been greatly improved

[0048] Based on the semantic comparison method defined by G4 formal grammar, a precise mapping relationship between the source and target is established at the grammatical production level, avoiding omissions and mismatches in string matching schemes. The accuracy of DDL transformation is significantly improved compared with traditional schemes, and it can correctly transform complex grammatical structures such as partitioned tables, encrypted columns, generated columns, and bitmap indexes.

[0049] (2) Comprehensive coverage of dialects

[0050] The system has built-in G4 formal syntax (approximately 31,000 lines of rules) for 6 major database dialects, supports bidirectional DDL conversion between various databases such as Oracle, MySQL, SQL Server, PostgreSQL, and OpenGauss, and has implemented more than 10 conversion channels.

[0051] (3) Low expansion cost and short cycle of adding new dialects

[0052] Adding a new database dialect only requires writing the corresponding G4 grammar file, parsing the Visitor, and translating the Visitor; the core AST model and pipeline require no modification. The modular G4 grammar design (split according to dimensions such as DDL / DML / DAL / DCL / TCL) further reduces the maintenance complexity of the grammar file.

[0053] (4) Flexible and configurable conversion strategies

[0054] It offers three conversion strategies: strict, lenient, and warning, as well as fine-grained configuration options such as strict / lenient for ENUM types and strict / lenient for partitioned syntax, to meet the differentiated needs of various business scenarios for conversion accuracy and compatibility. The three-level conversion rule system (AST rules, string rules, and mapping rules) can be combined as needed to achieve comprehensive control from syntax structure to text details.

[0055] (5) Supports real-time synchronization of incremental DDL

[0056] It not only supports full DDL conversion, but also cross-dialect conversion of incremental DDL such as ALTER TABLE RENAME, CREATE TABLE LIKE, ALTER TABLE ADD / DROP / MODIFY COLUMN. It can handle complex DDL change scenarios that simultaneously include VIEW, SEQUENCE, TABLE, and RENAME, meeting the needs of CDC real-time synchronization scenarios.

[0057] (6) Dual Visitor decoupling architecture, high cohesion and low coupling

[0058] By decoupling the Visitor parsing (ParseTree→AST) and the Visitor translation (AST→Target SQL), parsing and generation are completely independent. Adding a new conversion channel only requires combining the existing parser and translator, resulting in good scalability.

[0059] (7) Zero intrusion into business systems

[0060] It takes pure SQL text as input and output, does not depend on the connection of the source or target database, does not require the installation of any components in the database, does not require modification of the table structure or addition of auxiliary fields, and is completely transparent to the business system.

[0061] Other features and advantages of this application will be set forth in detail in the following description, or will become apparent through the implementation of the relevant technical solutions of this application. The objectives and other advantages of this application can be achieved through the technical features and means explicitly pointed out in the description, claims, and drawings, and will be obtained through the implementation of these technical contents. Attached Figure Description

[0062] To more clearly illustrate the technical solution of this application, the accompanying drawings involved in the description of this invention will be briefly introduced below. It should be noted that the drawings only show some embodiments of the invention. For those skilled in the art, other related drawings can be derived from these drawings without creative effort.

[0063] Figure 1 This diagram illustrates the operational steps of the cross-database dialect intelligent DDL conversion method based on G4 formal grammar comparison, as described in this application.

[0064] Figure 2 This is a structural diagram of the cross-database dialect intelligent DDL conversion device based on G4 formal grammar comparison in this application.

[0065] Figure 3 This is a diagram showing the overall design architecture of the system of the present invention.

[0066] Figure 4 This is a flowchart of the G4 syntax comparison and mapping process in the present invention.

[0067] Figure 5 This is the core flowchart of the DDL conversion method of the present invention.

[0068] Figure 6 This is a diagram of the decoupled architecture of the dual Visitor mode in the present invention.

[0069] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0070] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the protection scope of this application.

[0071] In this document, the term "comprising" and any variations thereof (such as "including," "including," etc.) are open-ended expressions and should be understood as "including but not limited to," meaning that the listed content is not exhaustive and may include other content not explicitly mentioned. The term "based on" should be understood as "at least partially based on," meaning that the basis or condition referred to may not be the only factor and may involve other relevant factors. The term "one embodiment" should be understood as "at least one embodiment," meaning that the described embodiment is not the only possible implementation, and other similar embodiments may exist.

[0072] In this application, the terms "a" and "a plurality of" are used to modify related elements or features, and their expression is illustrative rather than restrictive. Unless otherwise expressly stated in the context, "a" should be understood as "at least one," and "a plurality of" should be understood as "at least two." Those skilled in the art should reasonably interpret these terms based on the semantic and logical relationships of the context to ensure that they cover the possibility of "one or more."

[0073] This invention provides the following technical solutions:

[0074] This invention proposes a cross-database dialect intelligent DDL conversion method based on G4 formal grammar comparison.

[0075] Figure 5 This is the core flowchart of the DDL conversion method of the present invention, which clearly shows the complete processing flow from source DDL input to target DDL output, specifically including:

[0076] Input layer: Receives source DDL text input and supports multiple database dialects such as Oracle, MySQL, SQL Server, PostgreSQL, and OpenGauss.

[0077] Phase 1: Grammar Selection and Analysis

[0078] Based on the source database type, load the corresponding G4 grammar file, perform lexical analysis using ANTLR4 Lexer, and perform grammatical analysis using ANTLR4 Parser to generate ParseTree.

[0079] Phase Two: AST Construction

[0080] The Visitor traverses the ParseTree, automatically maintaining parent-child node relationships through the @Child annotation and reflection mechanism, constructing a unified AST model, and standardizing dialect-related grammar nodes into standard Segment objects.

[0081] Phase Three: Syntax Comparison and Mapping

[0082] By comparing the G4 syntax rules of the source and target databases, conversion difference rules are generated; cross-dialect data type mapping is performed through the DataTypeConverterFactory; a three-level conversion rule system is formed, including AST rules (handling syntactic structure differences), string rules (handling text-level differences), and mapping rules (handling semantic mapping); the three-level conversion rule system is applied to adjust the syntactic structure and adapt the semantics.

[0083] Phase 4: Target SQL Generation

[0084] The Visitor translation process traverses the AST, calling over 100 visit() methods to generate target dialect SQL node by node. After processing by the transformation strategy engine, it supports three strategy modes: strict, lenient, and warning.

[0085] Output layer: The final output is the target DDL text, in the target database dialect format.

[0086] To more clearly illustrate the technical solution of this application, the following will provide further explanation through specific scenario embodiments.

[0087] The core technical framework of this invention is "G4 formal syntax comparison + unified AST intermediate representation". By utilizing the syntax parsing capability of ANTLR4 and the traversal mechanism of the Visitor pattern, a unified semantic model across dialects is constructed to achieve intelligent parsing, accurate comparison and automatic conversion of DDL.

[0088] Figure 3 The overall design architecture diagram of the system of this invention clearly shows the five core architecture layers of this invention: G4 syntax definition layer (antlr4-dialect, which has built-in ANTLR4 syntax files for multiple database dialects), AST parsing layer (ddl-parser, which is a syntax tree construction driven by the visitor pattern), unified AST model layer (transform-base, a cross-dialect standardized model with 200+ segment classes), target SQL generation layer (ddl-translator, which is a multi-strategy conversion engine that translates visitors), and pipeline orchestration layer (transform-pipeline, which is a unified scheduling of the entire process through the TransformPipeline).

[0089] 1. G4 Syntax Definition Layer

[0090] A multi-dialect ANTLR4 formal syntax library was constructed as the semantic benchmark for the entire system. The system includes G4 syntax files for five database dialects: Oracle, MySQL, SQL Server, PostgreSQL, and OpenGauss, totaling approximately 31,000 lines of syntax rules. The G4 syntax files employ two organizational models: a monolithic model (Oracle, MySQL, etc., using a single parser file + a single lexer file) and a modular model (OpenGauss, PostgreSQL, etc., split into 12 import files based on dimensions such as DDL / DML / DAL / DCL / TCL / keywords / literals). The G4 syntax files precisely define the complete grammatical production rules for each dialect using EBNF normal form, covering all DDL syntax structures such as CREATE / ALTER / DROP TABLE, INDEX, SEQUENCE, VIEW, TYPE, TABLESPACE, DATABASE, TRIGGER, FUNCTION, and PROCEDURE, as well as DML structures such as SELECT / INSERT / UPDATE / DELETE / MERGE.

[0091] 2. AST parsing layer

[0092] Based on ANTLR4, a lexer and parser are generated from G4 grammar files. Using the Visitor Pattern, the source database DDL text is parsed into a ParseTree. The SQLParserEngine dynamically selects the appropriate parser based on the source database type; the SQLServiceEngine automatically routes to the corresponding dialect's Service implementation using reflection; each dialect implements an independent Visitor class (e.g., OracleDDLStatementSQLVisitor, MySQLDDLStatementSQLVisitor), and a unified SQL model object is constructed by traversing the ParseTree.

[0093] 3. Unified AST model layer

[0094] A unified SQL abstract syntax tree model is defined across dialects as a standardized intermediate representation between parsing and generation. The model is based on the ASTNode tree-like node system, automatically maintaining parent-child relationships through the @Child annotation and reflection. Organized semantically into a Segment system, it covers more than ten dimensions including column definitions, table definitions, partitions, indexes, expressions, functions, data types, views, sequences, constraints, tablespaces, and databases, totaling over 200 Segment classes. The model layer defines a TranslateVisitor interface for each Segment node, providing over 100 visit() methods as a unified entry point for cross-dialect conversion.

[0095] 4. G4 Syntax Comparison and Mapping Engine

[0096] Figure 4 The flowchart of G4 grammar comparison and mapping in this invention clearly shows the four core steps of cross-dialect G4 grammar comparison: grammar rule alignment—analyzing the corresponding grammar production nodes in the source G4 and target G4; grammar element mapping—establishing precise correspondences between the elements on the right side of the production rules (e.g., VARCHAR2→VARCHAR, NUMBER→NUMERIC); grammar difference marking—automatically identifying dialect-specific grammar structures and marking difference nodes; and conversion rule generation—generating conversion patch rules for the differences and loading them as needed.

[0097] The core mechanism of this invention is to automatically generate a mapping relationship between grammatical elements by comparing the G4 grammatical production rules of the source and target databases. Specifically, it includes:

[0098] Input layer: source database G4 syntax file (such as Oracle G4) and target database G4 syntax file (such as OpenGauss G4).

[0099] Step 1, Syntax Rule Alignment: Analyze the DDL-related production rules (such as create_table, alter_table) in the source G4 and target G4, identify the corresponding syntax production nodes and establish preliminary alignment relationships, for example: create_table ↔ create_table, alter_table ↔ alter_table, data_type ↔ data_type;

[0100] Step 2, Syntax Element Mapping: Compare the syntax elements on the right side of the production rule to establish an exact correspondence (e.g., Oracle's VARCHAR2 → OpenGauss's VARCHAR, Oracle's NUMBER → OpenGauss's NUMERIC, NUMBER → DECIMAL, CLOB → TEXT).

[0101] Step 3, Syntactic Difference Marking: Automatically identify dialect-specific syntactic structures (such as Oracle's partitioning syntax, MySQL's AUTO_INCREMENT, and SQL Server's IDENTITY) and mark them as difference nodes that require specific processing; examples include: Oracle's partitioning syntax, MySQL's AUTO_INCREMENT, SQL Server's IDENTITY, Oracle's ENABLE / DISABLE, etc.

[0102] Step 4, Transformation Rule Generation: Generate corresponding transformation strategies for the marked difference nodes and load them into the transformation pipeline as needed. Rule types include: AST rules (for handling syntactic structure differences), string rules (for handling text-level differences), and mapping rules (for handling semantic mapping).

[0103] Output layer: The final output is a set of transformation rules, which is loaded into the TransformPipeline for use in subsequent DDL transformations.

[0104] 5. Target SQL Generation Layer

[0105] Figure 6 This diagram illustrates the decoupled architecture of the dual-Visitor mode in the present invention. It clearly shows the architectural relationship between the parsing Visitor chain (ANTLR4 ParseTree → Unified AST) and the translation Visitor chain (Unified AST → Target Dialect SQL) connected through the Unified AST model, as well as the reusable extension mechanism that only requires adding a new Visitor implementation when adding a new dialect channel.

[0106] In this solution, based on the mapping rules generated by comparing the unified AST model with G4, the AST is converted into DDL statements in the target database dialect using a TranslateVisitor. The TranslateVisitor provides a dedicated `visit()` method for each DDL statement type through the generic interface `IStatementTranslateVisitor`. Three configurable conversion strategies are supported: strict mode (error occurs when mapping fails), lenient mode (downgrades to a compatible alternative when mapping fails), and warning mode (logs and continues execution when mapping fails). Data type conversion is implemented using the DataTypeConverterFactory in the factory pattern, with built-in cross-dialect type mappings for Oracle→OpenGauss, MySQL→OpenGauss, SQLServer→OpenGauss, and PostgreSQL→OpenGauss.

[0107] 6. Assembly line layout layer

[0108] TransformPipeline serves as a unified entry point, connecting the complete transformation process: receiving the source DDL and source / target database types → querying TransformTypeEnum to determine the transformation channel → SQLServiceEngine parsing the source SQL to generate AST → TranslateVisitorFactory creating translators in a factory-like manner → applying three levels of TranslateRules (AST rules handle syntactic structure differences, string rules handle text-level differences, and mapping rules handle semantic mapping) → generating the target SQL and encapsulating it as TransformResult for return.

[0109] In summary, this invention achieves intelligent, automated, and scalable conversion of cross-database dialect DDL through a five-layer closed-loop architecture of "G4 grammar definition - AST parsing - grammar comparison mapping - unified model - target generation".

[0110] The flowcharts and block diagrams in the accompanying drawings illustrate possible implementations of apparatus, methods, and computer program products according to various embodiments of this application, including architecture, functionality, and operation. In these figures, each block may represent a module, program segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should be noted that each block in the block diagrams and / or flowcharts, and combinations thereof, can be implemented using either a dedicated hardware-based system or a combination of dedicated hardware and computer instructions to achieve the specified function or operation.

[0111] like Figure 7 As shown in the illustration, an embodiment of this application also discloses an electronic device, including: a processor 310, a communication interface 320, a memory 330 for storing a processor-executable computer program, and a communication bus 340. The processor 310, communication interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 executes the executable computer program to implement the steps of the aforementioned cross-database dialect intelligent DDL conversion method based on G4 formal grammar comparison.

[0112] It is understood that, in addition to memory and a processor, this electronic device may also include input devices (such as a keyboard), output devices (such as a display), and other communication modules. These input devices, output devices, and other communication modules all communicate with the processor through I / O interfaces (i.e., input / output interfaces).

[0113] The operations described in this application can be implemented by writing computer program code using one or more programming languages ​​or a combination thereof. The programming languages ​​include, but are not limited to, the following types:

[0114] Object-oriented programming languages, such as Java, Smalltalk, C++, etc.

[0115] Conventional procedural programming languages, such as "C" or similar programming languages.

[0116] The execution methods of program code include, but are not limited to:

[0117] It runs entirely on the user's computer;

[0118] Part of it executes on the user's computer, and part of it executes on a remote computer;

[0119] Execute as a standalone software package;

[0120] It is executed entirely on a remote computer or server.

[0121] In scenarios involving remote computers, the remote computer can connect to the user's computer via any type of network, including but not limited to local area networks (LANs) or wide area networks (WANs). Furthermore, the remote computer can also connect to external computers through an internet service provider, for example, by utilizing the internet for connection.

[0122] Furthermore, this application also discloses a computer-readable storage medium, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the various steps of the cross-database dialect intelligent DDL conversion method based on G4 formal grammar comparison disclosed in this application.

[0123] In the context of this application, a computer-readable storage medium refers to a tangible medium capable of storing computer program code and related data. Specific examples include, but are not limited to, the following:

[0124] (1) Portable computer disk: such as floppy disks and other removable magnetic storage media.

[0125] (2) Hard disk: including mechanical hard disks and solid-state hard disks and other fixed storage devices.

[0126] (3) Random Access Memory (RAM): A volatile storage medium used for temporary storage of data and program code.

[0127] (4) Read-only memory (ROM): a non-volatile storage medium used to store fixed programs and data.

[0128] (5) Erasable programmable read-only memory (EPROM) or flash memory: non-volatile storage media that supports multiple erasures and reprogrammings.

[0129] (6) Fiber optic storage devices: storage media based on fiber optic technology.

[0130] (7) Portable compact disc read-only memory (CD-ROM): a read-only medium that stores data in the form of an optical disc.

[0131] (8) Optical storage devices: such as DVDs, Blu-ray discs and other storage media based on optical principles.

[0132] (9) Magnetic storage devices: such as magnetic tapes, disks and other storage media based on magnetic principles.

[0133] (10) Any suitable combination of the above: for example, combining multiple storage media to meet different storage needs.

[0134] These computer-readable storage media can be used to store the program code and related data described in this application to support program execution and persistent data storage.

[0135] Specifically, according to embodiments of this application, the processes described in the flowcharts can be implemented as computer software programs. For example, embodiments of this application relate to a computer program product comprising a computer program carried on a non-transitory computer-readable medium. This computer program includes program code for executing the cross-database dialect intelligent DDL conversion method based on G4 formal grammar comparison disclosed in this application. When this computer program is executed by a processing device, it can achieve the functions defined in the embodiments of this application.

[0136] While the foregoing discussion contains several specific implementation details, these details should not be construed as limiting the scope of this application. The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this application is not limited to technical solutions formed by specific combinations of the above-described technical features. Furthermore, this application should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the foregoing disclosed concept.

[0137] Those skilled in the art should also understand that modifications can be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features, without departing from the spirit and scope of the technical solutions of the embodiments of this application. These modifications or substitutions will not cause the essence of the corresponding technical solutions to deviate from the core spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A cross-database dialect intelligent DDL conversion method based on G4 formal grammar comparison, characterized in that, Includes the following steps: S1. Syntax Selection and Parsing: Receives source DDL text input and source database type, target database type; Load the corresponding ANTLR4 G4 grammar file according to the source database type, perform lexical analysis and grammatical analysis on the source DDL text in sequence, and generate the source parse tree (ParseTree). S2. Unified AST Construction: By traversing the ParseTree through the parser Visitor, the parent-child relationship between nodes is automatically maintained based on annotation and reflection mechanisms to construct a unified abstract syntax tree (AST) model across dialects; the parser Visitor implements an independent Visitor class for each database dialect, which is used to map dialect-related syntax nodes to standard Segment objects. S3. Syntax Comparison and Mapping: Compare the G4 grammar production rules of the source database and the target database, identify the corresponding grammar nodes and establish grammar element mapping relationships, automatically mark the difference nodes of dialect-specific grammar structures, and generate a three-level transformation rule system containing AST rules, string rules and mapping rules. S4. Target SQL Generation: By traversing the Unified Abstract Syntax Tree (AST) model through the Visitor translation, the visit() method corresponding to the DDL statement type is called to generate the target dialect SQL node by node, and then processed by the transformation strategy engine to output the target DDL text.

2. The method according to claim 1, characterized in that, The ANTLR4 G4 grammar file mentioned in step S1 defines the complete grammar production rules of the database dialect in the extended Backus paradigm. It is organized in either a monolithic or modular mode. The modular mode is split into multiple import files according to the dimensions of DDL, DML, DAL, DCL, TCL, keywords, and literals. The lexical and syntactic analysis is implemented based on ANTLR4.

3. The method according to claim 1, characterized in that, The standard Segment object described in step S2 is organized according to semantic dimensions, covering column definitions, table definitions, partitions, indexes, expressions, functions, data types, views, sequences, constraints, tablespaces, and database dimensions.

4. The method according to claim 1, characterized in that, The syntax comparison and mapping described in step S3 includes: S31. Syntax rule benchmarking: Analyze the DDL-related production rules in source G4 and target G4, identify the corresponding syntax production nodes and establish a preliminary benchmarking relationship; S32. Syntax element mapping: By comparing the syntactic elements on the right side of the production rule, a precise correspondence between the source dialect and the target dialect is established. S33, Syntactic Difference Marking: Automatically identifies grammatical structures unique to each dialect and marks them as difference nodes that require specific processing; S34. Transformation rule generation: Generate corresponding transformation strategies for the difference nodes and load them into the transformation pipeline as needed.

5. The method according to claim 1, characterized in that, The AST rules in step S3 are used to handle syntactic structural differences, the string rules are used to handle text-level differences, and the mapping rules are used to handle semantic mapping.

6. The method according to claim 1, characterized in that, In step S3, cross-dialect data type mapping is performed through a data type converter factory, which has built-in multiple sets of data type mapping relationships between database dialects.

7. The method according to claim 1, characterized in that, In step S4, the translation visitor generates the target DDL text through a conversion strategy engine. The conversion strategy engine supports three conversion strategies: strict mode, lenient mode, and warning mode. When mapping fails in strict mode, an error is reported. When mapping fails in lenient mode, it is downgraded to a compatible alternative. When mapping fails in warning mode, a log is recorded and execution continues.

8. The method according to claim 1, characterized in that, The method supports incremental DDL transformations, including ALTER TABLE RENAME, CREATE TABLE LIKE, and ALTER TABLE ADD / DROP / MODIFY COLUMN operation types.

9. The method according to claim 1, characterized in that, The source database type and the target database type are selected from any one of Oracle, MySQL, SQL Server, PostgreSQL, and OpenGauss, and the source database type and the target database type are different; The method takes plain SQL text as input and output, and does not depend on the connection to the source or target database.

10. A cross-database dialect intelligent DDL conversion device based on G4 formal grammar comparison, characterized in that, When the device is in operation, it implements the steps of the intelligent DDL conversion method for cross-database dialects based on G4 formal grammar comparison as described in any one of claims 1-9, including: The syntax selection and parsing module is used to receive the source DDL text input and the source database type and target database type; load the corresponding ANTLR4 G4 syntax file according to the source database type; perform lexical analysis and syntax analysis on the source DDL text in sequence; and generate the source syntax parse tree (ParseTree). A unified AST construction module is used to traverse the ParseTree by parsing the Visitor, automatically maintain the parent-child relationship between nodes based on annotation and reflection mechanisms, and construct a cross-dialect unified abstract syntax tree (AST) model; the parsing Visitor implements an independent Visitor class for each database dialect, which is used to map dialect-related syntax nodes to standard Segment objects. The grammar comparison and mapping module is used to compare the G4 grammar production rules of the source database and the target database, identify the corresponding grammar nodes and establish grammar element mapping relationships, automatically mark the difference nodes of dialect-specific grammar structures, and generate a three-level transformation rule system containing AST rules, string rules and mapping rules. The target SQL generation module is used to traverse the Unified Abstract Syntax Tree (AST) model by translating the Visitor, call the visit() method corresponding to the DDL statement type to generate target dialect SQL node by node, and process it through the transformation strategy engine to output the target DDL text.

Images