Multi-database compatible query processing method, equipment and medium

Abstract

The invention discloses a multi-database compatible query processing method and device and a medium, and relates to the technical field of data query processing. The method comprises the steps that according to configuration information of all compatible databases, dialect types of all the compatible databases are dynamically recognized, and corresponding dialect configuration rule sets are loaded; when an original SQL statement of the database operation is received, intercepting the original SQL statement before the database operation is executed through a preset interceptor mechanism; according to a dialect configuration rule set of the target database to be operated corresponding to the original SQL statement, reflecting and modifying the original SQL statement in the BoundSql object to obtain a standard SQL statement; and submitting the standard SQL statement to the to-be-operated target database for execution, and returning an execution result.

Description

Technical Field

[0001] The present application relates to the technical field of data query processing, and in particular to a multi-database compatible query processing method, device, and medium. Background Art

[0002] In today's enterprise application development, multi-database compatibility has become a core requirement for supporting heterogeneous system integration and data migration. However, significant differences exist between different databases in SQL syntax, paging mechanisms, and function implementation. For example, there are syntax conflicts with keywords like LIMIT, ROWNUM, and TOP in paging queries, differing symbolic interpretation between backticks and double quotes, and inconsistent implementation of date and string functions. These discrepancies force developers to write repetitive adaptation code for different databases, resulting in low development efficiency and increased maintenance costs.

[0003] Existing technologies typically use hard-coding to achieve multi-database adaptation, pre-setting multiple sets of SQL templates or conditional branching statements for syntax matching. This approach not only causes exponential growth in code redundancy and complexity, but also makes it difficult to cope with the continuous iteration requirements brought about by the access of new databases. Especially for databases with special syntax rules, traditional adaptation solutions require in-depth modifications to the SQL statement structure, which can easily introduce syntax errors or performance bottlenecks. In addition, existing database middleware generally lacks dynamic syntax conversion capabilities and is unable to automatically adjust SQL dialect rules based on the data source type at runtime, which severely limits the scalability and flexibility of the system.

[0004] Therefore, how to more efficiently solve the compatibility issues caused by SQL syntax differences in heterogeneous database environments has become a technical problem that technicians in this field urgently need to solve. Summary of the Invention

[0005] The embodiments of the present application provide a multi-database compatible query processing method, device, and medium to solve the following technical problem: how to more efficiently solve compatibility issues caused by SQL syntax differences in a heterogeneous database environment.

[0006] In the first aspect, an embodiment of the present application provides a multi-database compatible query processing method, the method comprising: dynamically identifying the dialect type of each compatible database based on the configuration information of each compatible database, and loading the corresponding dialect configuration rule set; when receiving the original SQL statement of the database operation, intercepting the original SQL statement before the database operation is executed through a preset interceptor mechanism; reflectively modifying the original SQL statement in the BoundSql object based on the dialect configuration rule set of the target database to be operated corresponding to the original SQL statement to obtain a standard SQL statement; submitting the standard SQL statement to the target database to be operated for execution, and returning the execution result.

[0007] In one embodiment of the present application, the dialect type of each compatible database is dynamically identified based on the configuration information of each compatible database, specifically including: parsing the configuration information of each compatible database to determine the corresponding database identifier; wherein the database identifier includes a database type identifier; matching the database identifier with a preset dialect type mapping table to determine the dialect type of each compatible database.

[0008] In one embodiment of the present application, loading the corresponding dialect configuration rule set specifically includes: reading the rule file corresponding to each compatible database from a preset rule storage path; wherein the rule file contains paging syntax conversion rules, special symbol processing rules and function compatibility mapping tables; converting the logical expressions in the rule file into executable rule objects in memory through a structured parser; loading the executable rule objects into the rule execution chain in priority order, and detecting whether the user-defined dialect plug-in contains extended rules; if extended rules exist, dynamically injecting the extended rules into the end of the rule execution chain to form a complete dialect configuration rule set.

[0009] In one embodiment of the present application, before intercepting the original SQL statement before the database operation is executed through a preset interceptor mechanism, the method also includes: constructing an interceptor mechanism, specifically including: implementing a custom interceptor instance based on the Interceptor interface of the MyBatis framework; registering the interceptor to the StatementHandler execution link of MyBatis through a dynamic proxy mechanism; configuring the interceptor trigger condition to be the pre-prepare method call stage of PreparedStatement; and initializing a reflection tool class to access the private SQL attribute field of the BoundSql object.

[0010] In one embodiment of the present application, the dialect configuration rule set includes: paging syntax conversion rules, special symbol processing rules and function mapping rules; according to the dialect configuration rule set of the target database to be operated corresponding to the original SQL statement, the original SQL statement in the BoundSql object is reflected and modified, specifically including: parsing the paging parameters in the original SQL, and converting the paging parameters into corresponding syntax structures according to the paging syntax conversion rules; based on the special symbol processing rules, identifying and replacing the field reference symbol type in the original SQL statement that is incompatible with the target database to be operated; based on the function mapping rules, replacing the unique functions in the original SQL statement with equivalent functions supported by the target database to be operated, and adjusting the parameter calling order.

[0011] In one embodiment of the present application, the paging parameters in the original SQL are parsed, and the paging keywords corresponding to the paging parameters are converted into corresponding grammatical structures according to the paging syntax conversion rules, specifically including: identifying the paging parameters and parameter offsets in the original SQL statement through regular matching; determining the logical position and packaging method of the paging parameters in the target database to be operated according to the paging syntax conversion rules of the target database; reorganizing the parameter values ​​of the paging parameters with parameter placeholders according to the grammatical structure of the target database to be operated, and generating a subquery or pseudo-column expression containing the target paging syntax; and embedding the reorganized paging parameters into the query body of the original SQL statement after performing boundary checking on the paging parameters.

[0012] In one embodiment of the present application, based on special symbol processing rules, the field reference symbol types in the original SQL statement that are incompatible with the target database to be operated are identified and replaced, specifically including: traversing the syntax tree of the original SQL statement to locate the field reference node containing database reserved characters; according to the symbol escape rules of the target database to be operated, replacing the original symbol with a compatible target escape character and adding an escape identifier; for nested reference symbol scenarios, peeling off the outer symbols layer by layer and reconstructing the field alias expression; performing syntax check on the replaced symbols to ensure that the scope of the field reference is consistent with the original semantics.

[0013] In one embodiment of the present application, based on the function mapping rules, the unique function in the original SQL statement is replaced with an equivalent function supported by the target database to be operated, and the parameter calling order is adjusted, specifically including: parsing the function name and parameter list in the function call node; matching the equivalent function name with compatible parameter quantity and type according to the function mapping rule table of the target database to be operated; transposing the parameter list or implicitly converting the type according to the function parameter order requirements of the target database to be operated; and automatically completing the default parameter values ​​supported by the target database to be operated for function calls that lack default parameters.

[0014] In a second aspect, an embodiment of the present application also provides a multi-database compatible query processing device, the device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute a multi-database compatible query processing method such as any one of the above items.

[0015] In a third aspect, an embodiment of the present application further provides a non-volatile computer storage medium for multi-database compatible query processing, which stores computer executable instructions. When the computer executable instructions are executed, a multi-database compatible query processing method such as any one of the above items is implemented.

[0016] A multi-database compatible query processing method, device and medium provided by the embodiment of the present application have the following beneficial effects: through dynamic SQL dialect adaptation and interceptor optimization mechanism, fully automatic compatible conversion of SQL syntax in a multi-database environment is achieved, significantly reducing the development and maintenance costs of heterogeneous database systems. Specifically, the dynamic modification of SQL statements based on the reflection mechanism can accurately adapt to the paging syntax, special symbols and function call rules of different databases, without the need for developers to manually write multiple sets of SQL codes, effectively improving the development efficiency of cross-database queries; at the same time, through extensible rule loading and plug-in mechanisms, it supports rapid access to new database types, filling the gap in existing technology support for domestic databases. In addition, based on the low-invasive design of the MyBatis native interceptor, while ensuring the accuracy of syntax conversion, the system performance loss can be significantly reduced, taking into account the efficiency and stability of enterprise-level applications, and providing reliable technical support for heterogeneous database collaboration scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings: Figure 1 A flowchart of a multi-database compatible query processing method provided in an embodiment of the present application; Figure 2 A schematic diagram of the internal structure of a multi-database compatible query processing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0018] To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0019] The embodiments of the present application provide a multi-database compatible query processing method, device, and medium to solve the following technical problem: how to more efficiently solve compatibility issues caused by SQL syntax differences in a heterogeneous database environment.

[0020] The technical solutions proposed in the embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0021] Figure 1 This is a flowchart of a multi-database compatible query processing method provided in an embodiment of the present application. Figure 1As shown, the embodiment of the present application provides a multi-database compatible query processing method, which specifically includes the following steps: Step 101: Dynamically identify the dialect type of each compatible database based on the configuration information of each compatible database, and load the corresponding dialect configuration rule set.

[0022] In one embodiment of the present application, the dialect type of each compatible database is dynamically identified based on the configuration information of each compatible database, specifically including: parsing the configuration information of each compatible database to determine the corresponding database identifier; wherein the database identifier includes a database type identifier; matching the database identifier with a preset dialect type mapping table to determine the dialect type of each compatible database.

[0023] In one embodiment of the present application, loading the corresponding dialect configuration rule set specifically includes: reading the rule file corresponding to each compatible database from a preset rule storage path; wherein the rule file contains paging syntax conversion rules, special symbol processing rules and function compatibility mapping tables; converting the logical expressions in the rule file into executable rule objects in memory through a structured parser; loading the executable rule objects into the rule execution chain in priority order, and detecting whether the user-defined dialect plug-in contains extended rules; if extended rules exist, dynamically injecting the extended rules into the end of the rule execution chain to form a complete dialect configuration rule set.

[0024] In this embodiment, the implementation of the dynamic identification of dialect types depends on the parsing and mapping matching of database configuration information. Specifically, the system extracts the unique identifier of the database by reading the data source connection parameters (such as database URL, driver class name) defined in the application layer configuration (such as application.yml file). For example, when it is detected that the JDBC connection URL of MySQL contains the jdbc:mysql: / / prefix, the system marks its identifier as mysql; for the Dameng database, it is identified as dameng type through the driver class name dm.jdbc.driver.DmDriver. It should be noted that the identifier is matched with the preset dialect type mapping table (such as {mysql: "MySQL", dameng: "Dameng"}) to determine the dialect type of the current data source.

[0025] After determining the dialect type, the system loads the corresponding dialect configuration rule set. It is understandable that the rule set is stored in the form of a file in a preset path (such as the / dialect / rules directory), which contains paging syntax conversion rules, special symbol processing rules, and function compatibility mapping tables. For example, for an Oracle database, the rule file defines how to convert the LIMIT offset, size paging syntax into a subquery structure of a ROWNUM pseudo-column; for a Hangao database, the rule file specifies that backticks `` be replaced with double quotes". It should be noted that the rule file is converted into an executable rule object in memory by a structured parser (such as a YAML parser), and a rule execution chain is constructed in order of priority.

[0026] Furthermore, if a user-defined dialect plugin exists (such as an extension pack for the Kaiwu database), the system will dynamically detect the extension rules in the plugin and append them to the end of the rule execution chain. For example, a user can use an extension plugin to add custom conversion logic for the TOP paging syntax for the DAMO database. Upon loading, the system will automatically merge the base rules with the extension rules to form a complete dialect configuration rule set. This mechanism ensures the system's rapid adaptability to new database types and syntax changes.

[0027] Through the above process, the system dynamically identifies the dialect types of different databases at runtime and loads a rule set adapted to their grammatical characteristics, providing precise rule support for the automatic conversion of subsequent SQL statements, thereby solving the grammatical compatibility problem in a multi-database environment.

[0028] Step 102: When the original SQL statement for the database operation is received, the original SQL statement is intercepted before the database operation is executed through a preset interceptor mechanism.

[0029] In one embodiment of the present application, before intercepting the original SQL statement before the database operation is executed through a preset interceptor mechanism, the method also includes: constructing an interceptor mechanism, specifically including: implementing a custom interceptor instance based on the Interceptor interface of the MyBatis framework; registering the interceptor to the StatementHandler execution link of MyBatis through a dynamic proxy mechanism; configuring the interceptor trigger condition to be the pre-prepare method call stage of PreparedStatement; and initializing a reflection tool class to access the private SQL attribute field of the BoundSql object.

[0030] In this embodiment, the implementation of the interceptor mechanism depends on the extensibility of the MyBatis framework. Specifically, the system implements a custom interceptor instance based on the Interceptor interface of MyBatis, and registers it in the StatementHandler execution link of MyBatis through a dynamic proxy mechanism. For example, when a user executes the SqlSession.selectList("queryUser") operation, the interceptor will intercept and obtain the original SQL statement and its associated BoundSql object before the SQL statement is compiled into PreparedStatement. It should be noted that the triggering condition of the interceptor is configured as the pre-prepare method call stage of PreparedStatement to ensure that the interception is completed before the SQL is submitted to the database driver. It is understandable that the core function of the interceptor is to capture the runtime context of the original SQL. Specifically, the system breaks through the private attribute access restrictions of the BoundSql object by initializing the reflection tool class (such as Spring's ReflectionUtils) and dynamically obtains its internal SQL field values. For example, for an original SQL statement containing SELECT * FROM userWHERE create_time>NOW() LIMIT 10, the interceptor extracts the complete SQL string and parameter mapping relationship from BoundSql through reflection. It is understandable that the implementation of "initializing the reflection tool class to access the private SQL attribute fields of the BoundSql object" provides the original data basis for subsequent syntax adaptation.

[0031] In addition, the registration and scope of the interceptor are flexible. For example, in a distributed multi-data source scenario, the system can bind independent interceptor instances to different data source instances to ensure that the dialect rule set and interception logic of each data source are executed in isolation. It should be noted that this design enables the interceptor to dynamically switch the adaptation strategy according to the data source bound to the current thread to avoid rule conflicts when operating heterogeneous databases such as MySQL and DAMO at the same time in the same application.

[0032] Through the above-mentioned interceptor mechanism, the system accurately captures the original statement and its context information before SQL execution, providing necessary input for subsequent dynamic adaptation based on the dialect rule set, thereby ensuring the accuracy and timeliness of multi-database syntax conversion.

[0033] Step 103: According to the dialect configuration rule set of the target database to be operated corresponding to the original SQL statement, the original SQL statement in the BoundSql object is reflected and modified to obtain a standard SQL statement.

[0034] In one embodiment of the present application, the dialect configuration rule set includes: paging syntax conversion rules, special symbol processing rules and function mapping rules; according to the dialect configuration rule set of the target database to be operated corresponding to the original SQL statement, the original SQL statement in the BoundSql object is reflected and modified, specifically including: parsing the paging parameters in the original SQL, and converting the paging parameters into corresponding syntax structures according to the paging syntax conversion rules; based on the special symbol processing rules, identifying and replacing the field reference symbol type in the original SQL statement that is incompatible with the target database to be operated; based on the function mapping rules, replacing the unique functions in the original SQL statement with equivalent functions supported by the target database to be operated, and adjusting the parameter calling order.

[0035] In one embodiment of the present application, the paging parameters in the original SQL are parsed, and the paging keywords corresponding to the paging parameters are converted into corresponding grammatical structures according to the paging syntax conversion rules, specifically including: identifying the paging parameters and parameter offsets in the original SQL statement through regular matching; determining the logical position and packaging method of the paging parameters in the target database to be operated according to the paging syntax conversion rules of the target database; reorganizing the parameter values ​​of the paging parameters with parameter placeholders according to the grammatical structure of the target database to be operated, and generating a subquery or pseudo-column expression containing the target paging syntax; and embedding the reorganized paging parameters into the query body of the original SQL statement after performing boundary checking on the paging parameters.

[0036] In one embodiment of the present application, based on special symbol processing rules, the field reference symbol types in the original SQL statement that are incompatible with the target database to be operated are identified and replaced, specifically including: traversing the syntax tree of the original SQL statement to locate the field reference node containing database reserved characters; according to the symbol escape rules of the target database to be operated, replacing the original symbol with a compatible target escape character and adding an escape identifier; for nested reference symbol scenarios, peeling off the outer symbols layer by layer and reconstructing the field alias expression; performing syntax check on the replaced symbols to ensure that the scope of the field reference is consistent with the original semantics.

[0037] In one embodiment of the present application, based on the function mapping rules, the unique function in the original SQL statement is replaced with an equivalent function supported by the target database to be operated, and the parameter calling order is adjusted, specifically including: parsing the function name and parameter list in the function call node; matching the equivalent function name with compatible parameter quantity and type according to the function mapping rule table of the target database to be operated; transposing the parameter list or implicitly converting the type according to the function parameter order requirements of the target database to be operated; and automatically completing the default parameter values ​​supported by the target database to be operated for function calls that lack default parameters.

[0038] In this embodiment, the reflective modification process performs multi-dimensional syntax adaptation on the original SQL statement based on the dialect configuration rule set of the target database. Specifically, the system first parses the dialect type of the target database to be operated (such as Oracle) and loads the matching paging syntax conversion rules, special symbol processing rules, and function mapping rules. For example, when the original SQL statement contains the LIMIT 10 OFFSET 5 paging syntax, the system converts it into a subquery structure of SELECT * FROM (SELECT t.*, ROWNUM rn FROM (...) t WHERE ROWNUM<= 15) WHERE rn>5 according to the Oracle dialect rules.

[0039] It is understandable that special symbol processing is a key step in syntax adaptation. Specifically, the system traverses the syntax tree nodes of the original SQL statement and locates field reference symbols that are incompatible with the target database (such as MySQL's backquotes). For example, for the SELECT order FROM table `` statement, the system replaces backquotes with double quotes according to Oracle's symbol rules to generate SELECT "order" FROM table. It should be noted that for nested symbol scenarios (such as multi-layer symbols in alias references), the system peels off the outer symbols layer by layer and reconstructs the expression to ensure that the field scope is consistent with the original semantics.

[0040] In addition, function mapping rules are used to solve function compatibility issues across different databases. In this embodiment, the system parses the function call node (such as NOW()) in the original SQL and queries the function mapping table of the target database to match an equivalent function (such as Oracle's SYSDATE). For example, when the original SQL contains CONCAT(str1, str2), the system converts it to str1 || str2 according to PostgreSQL's rules. It should be noted that for scenarios where the number or type of parameters do not match (such as the date function of the DM database requires explicit precision), the system automatically completes the default parameters or adjusts the order of the parameters to ensure the syntactical legality of the function call.

[0041] Finally, the system uses reflection to directly modify the private SQL property values ​​within the BoundSql object, injecting the adapted standard SQL statement into the execution chain. For example, the reflection utility class uses Java's Unsafe or Field.setAccessible(true) method to bypass access restrictions and dynamically update the SQL string content. This process uses syntax validation (such as checking for non-negative paging offsets and validating function parameter types) to avoid execution exceptions caused by rule errors, ensuring that the converted SQL statement can be correctly parsed and executed by the target database.

[0042] Step 104: Submit the standard SQL statement to the target database for execution, and return the execution result.

[0043] In this embodiment, the execution of the standard SQL statement depends on the seamless connection between the database driver and the JDBC protocol. Specifically, the system passes the SQL string and parameter binding information (such as the index and value of the precompiled placeholder ?) in the reflected modified BoundSql object to the target database driver to generate an executable PreparedStatement object. For example, when the standard SQL statement contains a paging subquery of the ROWNUM pseudo-column, the system compiles it into an execution plan recognizable by the Oracle database through the JDBC prepareStatement method, while retaining the binding logic of the original parameters (such as the paging offset offset=5 and size=10), ensuring that the parameter type and value are transmitted without loss during the conversion process.

[0044] Understandably, database execution result processing must be compatible with the native logic of ORM frameworks (such as MyBatis). Specifically, the ResultSet or update count (updateCount) returned by the target database is passed back to the application layer via the JDBC standard interface, where it is converted by the ORM framework into entity objects or primitive data types. For example, for paging queries, if an Oracle database returns a result set containing the rn pseudo-column, the system automatically filters this auxiliary column and extracts the original query fields, ensuring that the data structure obtained by the business layer is consistent with the original SQL expectations.

[0045] Furthermore, to address the unique execution requirements of domestic databases (such as the batch insert syntax optimization for the DM database), the system dynamically adjusts the JDBC commit strategy using the execution mode flags (e.g., batchMode: true) defined in the dialect rule set. For example, when detecting batch insert statements for the DM database, the system automatically enables the rewriteBatchedStatements parameter, merging multiple INSERT statements into a batch operation, thereby improving execution efficiency.

[0046] Through the above process, after completing the dynamic adaptation of SQL syntax, the system efficiently submits standardized SQL statements to the target database for execution, and fully retains the result processing capabilities of the ORM framework, ultimately achieving full-link compatibility of query operations in multiple database environments, significantly reducing the adaptation costs of developers.

[0047] The above is an embodiment of the method proposed in this application. Based on the same inventive concept, the embodiment of this application also provides a multi-database compatible query processing device, whose structure is as follows Figure 2 shown.

[0048] Figure 2 This is a schematic diagram of the internal structure of a multi-database compatible query processing device provided in an embodiment of the present application. Figure 2 As shown, the equipment includes: at least one processor 201; and, a memory 202 communicatively coupled to the at least one processor; The memory 202 stores instructions that can be executed by at least one processor, and the instructions are executed by the at least one processor 201 to enable the at least one processor 201 to: According to the configuration information of each compatible database, the dialect type of each compatible database is dynamically identified and the corresponding dialect configuration rule set is loaded; when the original SQL statement for database operation is received, the original SQL statement is intercepted before the database operation is executed through the preset interceptor mechanism; according to the dialect configuration rule set of the target database to be operated corresponding to the original SQL statement, the original SQL statement in the BoundSql object is reflectively modified to obtain a standard SQL statement; the standard SQL statement is submitted to the target database to be operated for execution, and the execution result is returned.

[0049] Some embodiments of the present application provide corresponding Figure 1 A non-volatile computer storage medium for multi-database compatible query processing stores computer executable instructions, wherein the computer executable instructions are configured as follows: According to the configuration information of each compatible database, the dialect type of each compatible database is dynamically identified and the corresponding dialect configuration rule set is loaded; when the original SQL statement for database operation is received, the original SQL statement is intercepted before the database operation is executed through the preset interceptor mechanism; according to the dialect configuration rule set of the target database to be operated corresponding to the original SQL statement, the original SQL statement in the BoundSql object is reflectively modified to obtain a standard SQL statement; the standard SQL statement is submitted to the target database to be operated for execution, and the execution result is returned.

[0050] The various embodiments in this application are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other. Each embodiment focuses on the differences from the other embodiments. In particular, the IoT device and media embodiments are generally similar to the method embodiments, so their description is relatively simple. For relevant portions, refer to the description of the method embodiments.

[0051] The system and medium provided in the embodiments of the present application correspond one-to-one to the method. Therefore, the system and medium also have similar beneficial technical effects to their corresponding methods. Since the beneficial technical effects of the method have been described in detail above, the beneficial technical effects of the system and medium will not be repeated here.

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

[0053] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0054] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0055] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0056] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0057] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0058] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0059] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0060] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims

1. A multi-database compatible query processing method, characterized in that: The method comprises: Dynamically identify the dialect type of each compatible database based on its configuration information and load the corresponding dialect configuration rule set; When receiving the original SQL statement of the database operation, the preset interceptor mechanism is used to intercept the original SQL statement before the database operation is executed; According to the dialect configuration rule set of the target database to be operated corresponding to the original SQL statement, reflectively modify the original SQL statement in the BoundSql object to obtain a standard SQL statement; Submit the standard SQL statement to the target database for execution and return the execution result.

2. A multi-database compatible query processing method according to claim 1, characterized in that: Dynamically identify the dialect type of each compatible database based on its configuration information, including: Parsing the configuration information of each compatible database to determine the corresponding database identifier; wherein the database identifier includes a database type identifier; The database identifier is matched with a preset dialect type mapping table to determine the dialect type of each compatible database.

3. The multi-database compatible query processing method according to claim 1, characterized in that: Load the corresponding dialect configuration rule set, including: Reading the rule files corresponding to each compatible database from a preset rule storage path; wherein the rule files include paging syntax conversion rules, special symbol processing rules and function compatibility mapping tables; Converting the logical expressions in the rule file into executable rule objects in memory through a structured parser; Loading the executable rule objects into the rule execution chain in order of priority, and detecting whether the user-defined dialect plug-in contains extended rules; If an extension rule exists, the extension rule is dynamically injected into the end of the rule execution chain to form a complete dialect configuration rule set.

4. The multi-database compatible query processing method according to claim 1, characterized in that: Before intercepting the original SQL statement by a preset interceptor mechanism before executing the database operation, the method further includes: Constructing the interceptor mechanism specifically includes: Implement a custom interceptor instance based on the Interceptor interface of the MyBatis framework; Register the interceptor to the StatementHandler execution link of MyBatis through the dynamic proxy mechanism; Configure the interceptor trigger condition to be the stage before the prepare method of PreparedStatement is called; Initialize the reflection utility class to access the private SQL property fields of the BoundSql object.

5. The multi-database compatible query processing method according to claim 1, characterized in that: The dialect configuration rule set includes: paging syntax conversion rules, special symbol processing rules and function mapping rules; Reflectively modifying the original SQL statement in the BoundSql object according to the dialect configuration rule set of the target database to be operated corresponding to the original SQL statement specifically includes: Parsing the paging parameters in the original SQL and converting the paging parameters into corresponding grammatical structures according to the paging grammar conversion rules; Based on the special symbol processing rules, identifying and replacing the field reference symbol type in the original SQL statement that is incompatible with the target database to be operated; Based on the function mapping rule, the specific function in the original SQL statement is replaced with an equivalent function supported by the target database to be operated, and the parameter calling order is adjusted.

6. The multi-database compatible query processing method according to claim 5, characterized in that: Parse the paging parameters in the original SQL and convert the paging keywords corresponding to the paging parameters into corresponding grammatical structures according to the paging grammar conversion rules, specifically including: Identify the paging parameters and parameter offsets in the original SQL statement through regular expression matching; Determine the logical position and packaging method of the paging parameters in the target database to be operated according to the paging syntax conversion rules of the target database; Reorganize the parameter placeholders of the paging parameter values ​​according to the grammatical structure of the target database to be operated, and generate a subquery or pseudo-column expression containing the target paging grammar; After performing boundary checking on the reorganized paging parameters, the query body of the original SQL statement is embedded.

7. The multi-database compatible query processing method according to claim 5, characterized in that: Based on the special symbol processing rules, identifying and replacing the field reference symbol type in the original SQL statement that is incompatible with the target database to be operated, specifically including: Traversing the syntax tree of the original SQL statement to locate the field reference node containing database reserved characters; According to the symbol escape rule of the target database to be operated, the original symbol is replaced with a compatible target escape symbol and an escape identifier is added; For nested reference symbol scenarios, the outer symbols are stripped layer by layer and the field alias expression is reconstructed; Perform syntax check on the replaced symbols to ensure that the scope of the field reference is consistent with the original semantics.

8. The multi-database compatible query processing method according to claim 5, characterized in that: Based on the function mapping rule, the specific function in the original SQL statement is replaced with an equivalent function supported by the target database to be operated, and the parameter calling order is adjusted, specifically including: Parse the function name and parameter list in the function call node; Matching equivalent function names with compatible parameter numbers and types according to the function mapping rule table of the target database to be operated; According to the function parameter sequence requirements of the target database to be operated, the parameter list is swapped or implicitly converted; For function calls that lack default parameters, automatically complete the default parameter values ​​supported by the target database to be operated.

9. A multi-database compatible query processing device, characterized in that: The device comprises: at least one processor; and, a memory communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the multi-database compatible query processing method according to any one of claims 1 to 8.

10. A non-volatile computer storage medium for multi-database compatible query processing, storing computer executable instructions, characterized in that: When the computer-executable instructions are executed, a multi-database compatible query processing method according to any one of claims 1 to 8 is implemented.

Images