Rapid database adaptation method and device, storage medium and electronic equipment
By using a database adaptation layer, the problems of high cost, long cycle, and high risk in the database migration process are solved, achieving low-intrusion, fast and controllable database migration, supporting multiple domestic databases, and ensuring SQL semantic consistency and system performance.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-29
- Publication Date
- 2026-03-31
AI Technical Summary
Existing technologies for database migration suffer from high costs, long cycles, and significant risks. This is especially true when migrating commercial or open-source databases to domestic databases, where differences in SQL syntax, built-in functions, and data types result in a large workload and poor controllability.
By introducing a database adaptation layer, the system obtains the application's execution request, establishes a proxy connection, intercepts the source SQL and obtains the execution context information, performs structured parsing to generate an intermediate representation structure, loads the dialect conversion rule set according to the target database type for node-level rewriting, generates the target SQL, calls the target database's native driver for execution, and finally performs compatibility encapsulation processing to return the adapted execution result.
It achieves low-intrusive database migration, reduces migration costs and risks, supports different types and versions of domestic databases, ensures semantic consistency of SQL before and after conversion, reduces errors, improves deployment efficiency, and enhances system performance and maintainability through caching and conversion logs.
Smart Images

Figure CN121764897A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of database technology, and more specifically, to a method, apparatus, storage medium, and electronic device for rapid database adaptation. Background Technology
[0002] In the process of localization and substitution of information systems, migrating business systems from existing commercial or open-source databases (such as MySQL and Oracle) to domestic databases (such as DM, Kingbase, and OceanBase) has become an inevitable trend. However, different database management systems have significant differences in SQL syntax, built-in functions, data types, and transaction semantics, which poses a huge challenge to the migration work.
[0003] Currently, there are two main migration solutions: one is to manually modify the SQL statements and business logic in the application line by line. This method is labor-intensive, time-consuming, error-prone, and costly. The other is to rely on the compatibility mode provided by the target database. However, this mode has limited coverage and cannot be unified between different domestic databases, resulting in poor controllability.
[0004] Therefore, there is an urgent need for a universal, low-intrusion, automated adaptation method to achieve smooth and rapid migration of application systems to various target domestic databases with minimal code modification costs. Summary of the Invention
[0005] This invention provides a method, apparatus, storage medium, and electronic device for rapid database adaptation, in order to solve the problems of high cost, long cycle, and high risk in database migration and transformation in the prior art.
[0006] In a first aspect, the present invention provides a method for rapid database adaptation, the method comprising: Retrieves the execution request initiated by the application, which contains the source SQL. Based on the execution request, a proxy connection is established with the target database, and the database execution object is enhanced to obtain an enhanced object; The source SQL is intercepted through the enhanced object, and the execution context information of the source SQL is obtained; The source SQL is parsed in a structured manner to generate the corresponding intermediate representation structure; Based on the type of the target database, load the corresponding dialect conversion rule set; Based on the dialect conversion rule set, the intermediate representation structure is rewritten at the node level to generate the target intermediate representation structure; Based on the target intermediate representation structure, render and generate target SQL that is compatible with the target database syntax; The target SQL is executed by calling the native driver of the target database to obtain the native execution result; The original execution result is encapsulated for compatibility to obtain an adapted execution result; the adapted execution result is then returned to the application.
[0007] Preferably, the dialect conversion rule set includes function mapping rules, syntax rewriting rules, data type mapping rules, and keyword and identifier processing rules; The syntax rewriting rules include at least pagination clause transformation rules for handling database pagination queries, and semantic transformation rules for handling insert conflict updates.
[0008] Preferably, the step of performing structured parsing of the source SQL to generate a corresponding intermediate representation structure further includes: Identify and extract placeholder parameters from the source SQL, and record the source sequence number of each placeholder in the intermediate representation structure.
[0009] Preferably, the step of rewriting the intermediate representation structure at the node level according to the dialect conversion rule set to generate the target intermediate representation structure further includes: When the node-level rewriting causes a change in the number or order of the placeholders, a mapping relationship is established between the source placeholders and the target placeholders in the target intermediate representation structure based on the source sequence number.
[0010] Preferably, before executing the target SQL by calling the native driver of the target database, the method further includes: Based on the mapping relationship, the parameter values bound to the source placeholder in the execution context information are rebound to the target placeholder corresponding to the target SQL.
[0011] Preferably, the compatibility encapsulation process for the native execution result includes: Standardize and package the result set interface; The generated keys returned by the target database are adapted and converted. Execution exception codes and error messages are mapped to a format compatible with the source database.
[0012] Preferably, the method further includes: At least one of the intermediate representation structure, the target intermediate representation structure, and the mapping relationship is cached; Record the transformation log from the source SQL to the target SQL, and output a list of incompatible SQL based on the transformation results.
[0013] In a second aspect, the present invention provides a database rapid adaptation device, comprising: The execution request retrieval module is used to retrieve execution requests initiated by the application that contain source SQL. The proxy connection establishment module is used to establish a proxy connection with the target database based on the execution request, and to enhance the database execution object to obtain an enhanced object; An execution context information acquisition module is used to intercept the source SQL through the enhanced object and obtain the execution context information of the source SQL; The intermediate representation structure generation module is used to perform structured parsing on the source SQL and generate the corresponding intermediate representation structure; The dialect conversion rule set loading module is used to load the corresponding dialect conversion rule set according to the type of the target database; The target intermediate representation structure generation module is used to rewrite the intermediate representation structure at the node level according to the dialect conversion rule set to generate the target intermediate representation structure. The target SQL generation module is used to render and generate target SQL that is compatible with the target database syntax based on the target intermediate representation structure. The native execution result acquisition module is used to call the native driver of the target database to execute the target SQL and obtain the native execution result; The result return module is used to perform compatibility encapsulation processing on the original execution result to obtain an adapted execution result; and to return the adapted execution result to the application.
[0014] Thirdly, the present invention provides a readable medium including executable instructions, which, when executed by a processor of an electronic device, cause the electronic device to perform any of the methods described in the first aspect.
[0015] Fourthly, the present invention provides an electronic device including a processor and a memory storing execution instructions, wherein when the processor executes the execution instructions stored in the memory, the processor performs the method as described in any of the first aspects.
[0016] This invention provides a method, apparatus, storage medium, and electronic device for rapid database adaptation. The method involves: acquiring an execution request initiated by an application containing source SQL; establishing a proxy connection with the target database based on the execution request and enhancing the database execution object to obtain an enhanced object; intercepting the source SQL through the enhanced object and obtaining the source SQL execution context information; performing structured parsing on the source SQL to generate a corresponding intermediate representation structure; loading a corresponding dialect conversion rule set according to the target database type; rewriting the intermediate representation structure at the node level according to the dialect conversion rule set to generate a target intermediate representation structure; rendering and generating target SQL that is syntax-compatible with the target database based on the target intermediate representation structure; executing the target SQL by calling the target database's native driver to obtain the native execution result; performing compatibility encapsulation processing on the native execution result to obtain an adapted execution result; and returning the adapted execution result to the application. This invention achieves a low-intrusion database migration solution by introducing a database adaptation layer. Applications only need to change the data source configuration or use the proxy driver, without large-scale modifications to business code and SQL statements, effectively reducing migration costs and risks. Through a pluggable dialect conversion rule set, it can flexibly support different types and versions of domestic databases, possessing good versatility and scalability. Based on an abstract syntax tree or intermediate representation, the structured parsing and node-level rewriting mechanism, compared to plain text replacement, maximizes the semantic consistency and controllability of SQL before and after conversion, significantly reducing errors. Centralized rule configuration and repair can take effect globally, greatly reducing manual rewriting and integration testing time, improving overall deployment efficiency. Simultaneously, the system supports caching of parsing and conversion results to reduce runtime overhead and provides conversion logs, incompatibility lists, and other operational information, facilitating troubleshooting and continuous optimization, enhancing system performance and maintainability.
[0017] The further effects of the aforementioned non-conventional preferred method will be explained below in conjunction with specific embodiments. Attached Figure Description
[0018] To more clearly illustrate the embodiments of the present invention or the existing technical solutions, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0019] Figure 1 This is a schematic diagram of a database fast adaptation method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of another database fast adaptation method provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of a database rapid adaptation device provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation
[0020] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.
[0021] In the process of localization and substitution of information systems, migrating business systems from existing commercial or open-source databases (such as MySQL and Oracle) to domestic databases (such as DM, Kingbase, and OceanBase) has become an inevitable trend. However, different database management systems have significant differences in SQL syntax, built-in functions, data types, and transaction semantics, which poses a huge challenge to the migration work.
[0022] Currently, there are two main migration solutions: one is to manually modify the SQL statements and business logic in the application line by line. This method is labor-intensive, time-consuming, error-prone, and costly. The other is to rely on the compatibility mode provided by the target database. However, this mode has limited coverage and cannot be unified between different domestic databases, resulting in poor controllability.
[0023] Therefore, there is an urgent need for a universal, low-intrusion, automated adaptation method to achieve smooth and rapid migration of application systems to various target domestic databases with minimal code modification costs.
[0024] In view of this, the present invention provides a method for rapid database adaptation. See also Figure 1 The image shows a specific embodiment of a database fast adaptation method provided by the present invention. The method includes:
[0025] Step 101: Obtain the execution request initiated by the application, which contains the source SQL; Specifically, this step is the trigger point for the adaptation process. The application refers to a business software system that relies on a database for data access, such as web services or enterprise management software developed using Java Spring, .NET, or Go. In this solution, the application is initially developed based on a source database (such as MySQL), and contains database operation code written using the source database's SQL syntax. An execution request refers to a call initiated by the application during runtime through its data access layer (such as JDBC, ODBC, or ORM framework) to request the database to perform a certain operation. The core payload of this request is a source SQL statement conforming to the source database's syntax specifications, possibly accompanied by metadata such as parameters and transaction attributes. The adaptation layer receives the request here, establishing the data source for subsequent processing. In this step, the database adaptation layer acts as a transparent proxy, receiving and carrying the request, establishing the data input source for the entire adaptation process. The database adaptation layer is an intermediate component deployed between the application and the target database to achieve SQL syntax conversion and execution result compatibility. Its specific implementation can be a proxy driver, an embedded library, or a standalone proxy service.
[0026] Step 102: Establish a proxy connection with the target database based on the execution request, and enhance the database execution object to obtain an enhanced object; Furthermore, in this embodiment, the proxy connection is not a direct physical connection to the target database, but a logical connection object created and managed by the database adaptation layer. This object exposes standard database connection interfaces (such as java.sql.Connection) to the outside (to the application), while internally encapsulating the connection to the real target database and the adaptation logic. The database execution object refers to the object used to carry and execute SQL statements in the standard database access interface. In JDBC, this is specifically manifested as instances of interfaces such as Statement, PreparedStatement, and CallableStatement. The enhancement object refers to the object generated after extending the functionality of the native database execution object through dynamic proxy, bytecode enhancement, or wrapper patterns. Its core enhancement capability is that when the execution method is called, control is transferred to the adaptation layer instead of being sent directly to the database. Furthermore, when the application requests a connection, the adaptation layer establishes a physical connection using the real driver of the target database, but returns a proxy connection object that implements the same interface. When the application creates a statement through this proxy connection, the enhanced proxy statement object is returned.
[0027] Step 103: Intercept the source SQL by enhancing the object and obtain the source SQL execution context information; Furthermore, when the application calls the execution methods of the aforementioned enhancement object (such as `execute()` and `executeQuery()`), the interception logic implanted in the adaptation layer is triggered. At this time, the enhancement object captures the original source SQL string to be executed and synchronously obtains the complete execution context information associated with this call. This context information is a collection of metadata, mainly including: parameter values and data types bound through the `PreparedStatement.setXXX()` method, the current transaction status, the query timeout setting, and the expected result set type, etc.
[0028] Step 104: Perform structured parsing on the source SQL to generate the corresponding intermediate representation structure; Furthermore, the adaptation layer can invoke its SQL parsing module to perform structured parsing of the intercepted source SQL. This process includes lexical analysis and syntax analysis, converting the text-formatted SQL statement into a tree-like data structure that is easily traversed and manipulated by computer programs—an intermediate representation structure, often referred to as an abstract syntax tree or intermediate representation in the compiler field. This structure precisely expresses the semantic composition of the SQL. During this process, placeholder parameters in the source SQL can also be identified and extracted, and the source sequence number of each placeholder is recorded in the intermediate representation structure. Placeholder parameters are the "?" symbols in the pre-compiled statement. In the generated intermediate representation structure, the original order of appearance of each placeholder is recorded. For example, for the SQL "SELECT * FROM tWHERE a = ? AND b = ?", the source sequence number of the first "?" is 1, and the second is 2. This step elevates the SQL from a string into a programmable semantic model and provides a crucial indexing basis for solving the parameter consistency problem of pre-compiled statements after structural transformation.
[0029] Step 105: Load the corresponding dialect conversion rule set according to the type of the target database; The dialect conversion rule set includes function mapping rules, syntax rewriting rules, data type mapping rules, and keyword and identifier processing rules. The syntax rewriting rules include at least pagination clause conversion rules for handling database pagination queries, and semantic conversion rules for handling insert conflict updates. Specifically, the adaptation layer loads the corresponding dialect conversion rule set from its rule base based on the pre-configured or dynamically identified target database type. This rule set is a pluggable configuration package specific to a particular target database, containing at least the following four types of rules:
[0030] Function mapping rules: Define the conversion relationship between built-in functions in the source database and the target database. For example, map MySQL's IFNULL(a, b) function to DM's NVL(a, b) function; map NOW() function to CURRENT_TIMESTAMP or SYSDATE; map GROUP_CONCAT(x) to LISTAGG(x, ',') WITHIN GROUP (ORDERBY x).
[0031] Syntax rewriting rules: Define the transformation logic for SQL clause-level structures. It includes at least two core categories of rules: pagination clause transformation rules, used to transform pagination query syntax between different databases. For example, converting MySQL's `LIMIT 10OFFSET 20` syntax to `OFFSET 20 ROWS FETCH NEXT 10ROWS ONLY` syntax, which conforms to the SQL standard or is supported by the target database; and semantic transformation rules for handling insert conflict updates, used to handle database operations with "update if exists, insert otherwise" semantics. For example, converting MySQL's specific `INSERT ... ON DUPLICATE KEY UPDATE ...` syntax to an equivalent semantic structure supported by the target database, such as the standard `MERGE` statement or PostgreSQL's `INSERT ... ON CONFLICT ... DO UPDATE SET ...` statement.
[0032] Data type mapping rules: Define the conversion relationships between types in table structure or data operations. For example, map INTAUTO_INCREMENT to the IDENTITY keyword or sequence; map TINYINT(1) to BOOLEAN or SMALLINT; map TEXT type to CLOB.
[0033] Keyword and identifier handling rules: Handling reserved word conflicts and differences in identifier citation formats. For example, converting the backticks `col` used in MySQL to the double quotes "col" that the target database may require.
[0034] This step provides the adaptation engine with all the "dictionary" and "grammar" rules needed to perform accurate translation.
[0035] Step 106: Based on the dialect conversion rule set, rewrite the intermediate representation structure at the node level to generate the target intermediate representation structure; Furthermore, based on the loaded dialect conversion rule set, the intermediate representation structure is traversed, and its nodes are identified and rewritten at the node level. This is a semantic-based conversion process, and a typical conversion example is as follows:
[0036] For paginated queries, the "LIMIT-OFFSET" node subtree in the source SQL "SELECT * FROM t ORDER BY id LIMIT 10 OFFSET 20;" is rewritten into the "OFFSET 20 ROWS FETCH NEXT10 ROWS ONLY" structure supported by the target database. For insert conflict update operations, the MySQL statement "INSERT INTO t(id,val) VALUES(1,'x') ONDUPLICATE KEY UPDATE val='y';" is rewritten to an equivalent structure using the MERGE statement from the target database. For function calls, replace the IFNULL(a,b) node with the NVL(a,b) node.
[0037] In this embodiment, the target intermediate representation structure refers to the new structured data model generated after the intermediate representation structure of the source SQL is rewritten at the node level according to dialect conversion rules. This model conforms to the semantic specifications of the target database (such as DM or Kingbase). It is an intermediate product in the SQL conversion process, located between "conversion" and "final code generation," and is a machine-readable SQL semantic representation in memory. The target intermediate representation structure is usually represented as an abstract syntax tree, whose nodes contain various elements that have been converted and conform to the target database specifications. For example, statement structure nodes: the rewritten statement types (such as SELECT, MERGE). Function call nodes: the function names have been converted according to function mapping rules (such as NVL(...) replacing IFNULL(...)). Paging nodes: may have changed from LimitClause to OffsetFetchClause. Insert / update nodes: may have changed from InsertOnDuplicateKeyUpdate to a complex subtree of the Merge statement. Data type nodes: the type identifiers in the table definition or expression have been updated according to data type mapping rules (such as BOOLEAN replacing TINYINT(1)). Identifier nodes: Reference symbols for table names and column names may have been processed (e.g., double quotes replaced backticks). Placeholder parameter nodes: Their order and number may have changed due to structure rewriting, and a mapping relationship has been established with the source placeholders.
[0038] If the rewriting causes changes in the number or order of placeholder parameters, the system will dynamically establish a mapping table from source placeholders to target placeholders based on the source sequence number recorded in step 104. This step is crucial for ensuring the correctness of the SQL semantics after conversion.
[0039] Step 107: Based on the target intermediate representation structure, render and generate target SQL that is compatible with the target database syntax; Furthermore, the rewritten target intermediate representation structure is re-rendered according to the target database's syntax specifications to generate a standard SQL string, i.e., the target SQL. For example, the abstract syntax tree containing the pagination semantic subtree is rendered according to the target database's syntax specifications to generate the text "SELECT * FROM t ORDER BY id OFFSET 20 ROWSFETCH NEXT 10 ROWS ONLY". Here, "OFFSET 20 ROWS FETCH NEXT 10 ROWS ONLY" is the target SQL fragment corresponding to the pagination semantic subtree. This step produces the final SQL instruction that can be directly executed by the target database.
[0040] Step 108: Call the target database's native driver to execute the target SQL and obtain the native execution result; Furthermore, before executing the target SQL by calling the target database's native driver, the parameter values bound to the source placeholders in the execution context information are rebound to the corresponding target placeholders in the target SQL according to the mapping relationship. For precompiled statement objects, parameter rebinding must be performed before executing the target SQL. Based on the mapping relationship established in step 106, the adaptation layer precisely extracts the parameter values bound to each source placeholder from the execution context information obtained in step 103, and then rebinds them to the corresponding target placeholder positions in the target SQL. After completing the parameter rebinding, the adaptation layer executes the target SQL through the target database's native driver. The target database's native driver refers to the client library provided by the database vendor for connecting to and operating the database, such as DM's DmJdbcDriver. After calling the driver, the native execution results returned by the database are obtained, including: result set, number of affected rows, batch execution results, generated keys, etc. This step ensures that parameter semantics are transmitted losslessly after complex SQL structure transformations and utilizes the native driver to guarantee optimal compatibility and performance.
[0041] Step 109: Perform compatibility encapsulation on the original execution result to obtain the adapted execution result; return the adapted execution result to the application.
[0042] Furthermore, the native execution results returned by the target database may differ from the results expected by the application based on the source database driver in terms of interface format, data format, and exception handling. Therefore, compatibility encapsulation of the native execution results is necessary. This includes: standardizing the result set interface by packaging the ResultSet object returned by the target driver into an interface format familiar to the application; adapting and converting generated keys by converting generated key values such as auto-incrementing primary keys returned by the target database into a format expected by the application; and performing exception mapping to capture native exceptions thrown by the target database and convert their error codes and messages into an exception format simulating the source database, according to predefined mapping rules. Finally, an adapted execution result that is completely transparent to the application is generated and returned to the application through the initial call chain, thus completing a complete, non-intrusive database operation adaptation for the application.
[0043] As can be seen from the above technical solutions, the beneficial effects of this embodiment are as follows: This embodiment achieves extremely low invasiveness through a fully automated database adaptation process, allowing applications to migrate without modifying their code; structured parsing and node-level rewriting ensure the absolute accuracy of semantic transformation, completely solving industry problems such as pre-compiled statement parameter mapping; pluggable rule sets support multiple domestic databases, and centralized rule management significantly improves migration efficiency and maintainability; runtime caching ensures high performance, and complete result encapsulation provides comprehensive compatibility guarantees, ultimately transforming the migration of domestic databases from a high-risk, high-cost process into an efficient, reliable, and standardized technical process.
[0044] Figure 1 The embodiments shown are merely basic examples of the method of the present invention. Other preferred embodiments of the method can be obtained by making certain optimizations and extensions based on them.
[0045] like Figure 2 The image shows another specific embodiment of a database fast adaptation method according to the present invention. This embodiment further describes the method based on the foregoing embodiments, and includes the following steps:
[0046] Step 201: Cache at least one of the intermediate representation structure, the target intermediate representation structure, and the mapping relationship; Specifically, this step reduces the runtime overhead and improves processing efficiency during database adaptation through a caching mechanism. The cached objects involved include at least one of the following: intermediate representation structure, target intermediate representation structure, and mapping relationship. The intermediate representation structure refers to a computer-manufacturing data model (such as an Abstract Syntax Tree, AST) generated after structured parsing of the source SQL. The target intermediate representation structure refers to a new data model conforming to the semantics of the target database, obtained by rewriting the intermediate representation structure at the node level according to a dialect conversion rule set. The mapping relationship specifically refers to the correspondence table between source placeholder indices and target placeholder indices established during node-level rewriting when the number or order of placeholder parameters changes.
[0047] During implementation, after processing a source SQL statement for the first time, the adaptation layer stores the results of one or more structured processing methods in an in-memory cache or a distributed cache. When the same source SQL statement or one with only different parameter values is requested for execution again, the adaptation layer first attempts to find the corresponding intermediate representation structure, target intermediate representation structure, or mapping relationship from the cache. If a match is found, the time-consuming parsing and rewriting steps can be skipped directly, significantly reducing CPU computation and memory allocation, and significantly improving response speed. This mechanism is particularly suitable for enterprise applications with a large number of repetitive query statements, report SQL statements, or transaction processing logic, and is a key performance guarantee for achieving rapid adaptation. The caching strategy is configurable, such as being managed based on the LRU (Least Recently Used) algorithm, and supports invalidation and refresh mechanisms to ensure the correctness of data after rule updates.
[0048] Step 202: Record the transformation log from source SQL to target SQL, and output a list of incompatible SQL based on the transformation status.
[0049] Specifically, this step focuses on the observability and maintainability of the adaptation process. Through systematic logging and inventory output, it provides data support for migration project acceptance, problem identification, and continuous iteration of the rule base. Specifically, the adaptation layer records a complete transformation log for each source SQL statement to its corresponding target SQL statement. The log content includes not only the text of the source and target SQL statements but also detailed contextual information such as the transformation time, success / failure status, the specific transformation rule applied (e.g., which function mapping or syntax rewriting rule it applies to), and the parameter mapping relationship before and after the transformation. Based on the comprehensive recording of the transformation process, the system can output a list of incompatible SQL statements. This list mainly comes from two categories: first, SQL statements that failed to execute during transformation, such as encountering unparseable syntax or functions not defined in the rule base; and second, SQL statements that were successfully transformed but may have potential semantic risks or require manual review. This list is an important basis for migration evaluation and optimization. Operations personnel or database experts can use this information to analyze the root causes of incompatibility and then develop new function mapping rules, syntax rewriting rules, data type mapping rules, or keyword processing rules to supplement and optimize the dialect conversion rule set. Through this closed loop of "execution-recording-analysis-optimization," the compatibility coverage and conversion accuracy of the adaptation layer can be continuously improved, supporting the entire lifecycle from migration verification to long-term stable operation. Simultaneously, the conversion logs and checklists provide objective and detailed audit evidence for project acceptance.
[0050] As can be seen from the above technical solutions, the beneficial effects of this embodiment are as follows: By introducing a caching mechanism and monitoring and auditing functions, this embodiment significantly improves the runtime performance and long-term maintainability of the system. The caching mechanism minimizes the processing overhead of repetitive SQL statements by reusing parsing and transformation results, ensuring efficient response and low resource consumption in the production environment, and achieving the core requirement of rapid adaptation. The monitoring and auditing functions provide complete observability for the migration process through detailed transformation logs and incompatibility lists, making problem localization, rule optimization, and project acceptance evidence-based and continuously iterative, thereby systematically improving adaptation coverage and overall quality.
[0051] like Figure 3 The image shows a specific embodiment of a database rapid adaptation device according to the present invention. This embodiment of the device is used to execute... Figures 1-2 The physical apparatus of the method. Its technical solution is essentially the same as the above embodiments, and the corresponding descriptions in the above embodiments also apply to this embodiment. The apparatus in this embodiment includes:
[0052] The execution request acquisition module 301 is configured to acquire execution requests initiated by the application that contain source SQL. The proxy connection establishment module 302 is configured to establish a proxy connection with the target database based on the execution request and to enhance the database execution object to obtain an enhanced object; The execution context information acquisition module 303 is configured to intercept the source SQL through the enhanced object and obtain the execution context information of the source SQL; The intermediate representation structure generation module 304 is configured to perform structured parsing of the source SQL and generate the corresponding intermediate representation structure. The dialect conversion rule set loading module 305 is configured to load the corresponding dialect conversion rule set according to the type of the target database; The target intermediate representation structure generation module 306 is configured to rewrite the intermediate representation structure at the node level according to the dialect conversion rule set to generate the target intermediate representation structure. The target SQL generation module 307 is configured to render and generate target SQL that is compatible with the target database syntax based on the target intermediate representation structure. The native execution result acquisition module 308 is configured to call the native driver of the target database to execute the target SQL and obtain the native execution result; The result return module 309 is configured to perform compatibility encapsulation processing on the native execution result to obtain the adapted execution result; and return the adapted execution result to the application.
[0053] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. The memory may include main memory, such as high-speed random-access memory (RAM), or it may also include non-volatile memory, such as at least one disk storage device. Of course, the electronic device may also include other hardware required for other services.
[0054] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.
[0055] Memory is used to store instructions for execution. Specifically, instructions for execution are computer programs that can be executed. Memory can include main memory and non-volatile memory, and it provides the processor with execution instructions and data.
[0056] In one possible implementation, the processor reads the corresponding execution instructions from non-volatile memory into memory and then executes them. Alternatively, it can obtain the corresponding execution instructions from other devices to form a database fast adaptation device at the logical level. The processor executes the execution instructions stored in memory to implement the database fast adaptation method provided in any embodiment of the present invention through the executed instructions.
[0057] The above is as described in the present invention. Figure 3 The method executed by the database fast adaptation device provided in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this invention. The general-purpose processor can be a microprocessor or any conventional processor.
[0058] The steps of the method disclosed in the embodiments of this invention can be directly manifested as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.
[0059] This invention also proposes a readable medium storing execution instructions. When these instructions are executed by a processor of an electronic device, the electronic device can perform a fast database adaptation method provided in any embodiment of this invention, specifically for executing, for example... Figure 1 , Figure 2 The method shown.
[0060] The electronic devices in the foregoing embodiments may be computers.
[0061] Those skilled in the art will understand that embodiments of the present invention can be provided as methods or computer program products. Therefore, the present invention can be implemented in a completely hardware embodiment, a completely software embodiment, or a combination of software and hardware.
[0062] The various embodiments in this invention are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.
[0063] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0064] The above are merely embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the claims of the present invention.
Claims
1. A method for rapid database adaptation, characterized in that, The method includes: Retrieves the execution request initiated by the application, which contains the source SQL. Based on the execution request, a proxy connection is established with the target database, and the database execution object is enhanced to obtain an enhanced object; The source SQL is intercepted through the enhanced object, and the execution context information of the source SQL is obtained; The source SQL is parsed in a structured manner to generate the corresponding intermediate representation structure; Based on the type of the target database, load the corresponding dialect conversion rule set; Based on the dialect conversion rule set, the intermediate representation structure is rewritten at the node level to generate the target intermediate representation structure; Based on the target intermediate representation structure, render and generate target SQL that is compatible with the target database syntax; The target SQL is executed by calling the native driver of the target database to obtain the native execution result; The original execution result is encapsulated for compatibility to obtain an adapted execution result; the adapted execution result is then returned to the application.
2. The method according to claim 1, characterized in that, The dialect conversion rule set includes function mapping rules, syntax structure rewriting rules, data type mapping rules, and keyword and identifier processing rules; The syntax rewriting rules include at least pagination clause transformation rules for handling database pagination queries, and semantic transformation rules for handling insert conflict updates.
3. The method according to claim 1, characterized in that, The step of performing structured parsing of the source SQL to generate a corresponding intermediate representation structure also includes: Identify and extract placeholder parameters from the source SQL, and record the source sequence number of each placeholder in the intermediate representation structure.
4. The method according to claim 3, characterized in that, The step of rewriting the intermediate representation structure at the node level according to the dialect conversion rule set to generate the target intermediate representation structure further includes: When the node-level rewriting causes a change in the number or order of the placeholders, a mapping relationship is established between the source placeholders and the target placeholders in the target intermediate representation structure based on the source sequence number.
5. The method according to claim 4, characterized in that, Before executing the target SQL by calling the native driver of the target database, the process also includes: Based on the mapping relationship, the parameter values bound to the source placeholder in the execution context information are rebound to the target placeholder corresponding to the target SQL.
6. The method according to claim 1, characterized in that, The compatibility encapsulation process for the native execution result includes: Standardize and package the result set interface; The generated keys returned by the target database are adapted and converted. Execution exception codes and error messages are mapped to a format compatible with the source database.
7. The method according to any one of claims 1-6, characterized in that, The method further includes: At least one of the intermediate representation structure, the target intermediate representation structure, and the mapping relationship is cached; Record the transformation log from the source SQL to the target SQL, and output a list of incompatible SQL based on the transformation results.
8. A database rapid adaptation device, characterized in that, include: The execution request retrieval module is used to retrieve execution requests initiated by the application that contain source SQL. The proxy connection establishment module is used to establish a proxy connection with the target database based on the execution request, and to enhance the database execution object to obtain an enhanced object; An execution context information acquisition module is used to intercept the source SQL through the enhanced object and obtain the execution context information of the source SQL; The intermediate representation structure generation module is used to perform structured parsing on the source SQL and generate the corresponding intermediate representation structure; The dialect conversion rule set loading module is used to load the corresponding dialect conversion rule set according to the type of the target database; The target intermediate representation structure generation module is used to rewrite the intermediate representation structure at the node level according to the dialect conversion rule set to generate the target intermediate representation structure. The target SQL generation module is used to render and generate target SQL that is compatible with the target database syntax based on the target intermediate representation structure. The native execution result acquisition module is used to call the native driver of the target database to execute the target SQL and obtain the native execution result; The result return module is used to perform compatibility encapsulation processing on the original execution result to obtain the adapted execution result. The adaptation execution result is returned to the application.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed, performs the method of any one of claims 1 to 7.
10. An electronic device, characterized in that, The electronic device includes: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to implement the method described in any one of claims 1 to 7.
Citation Information
Cited By
A database dialect transaction semantic compatibility method, device and medium
CN122332365A