Oracle compatible method and equipment based on database driving program

Abstract

The embodiment of the invention discloses an Oracle compatible method and equipment based on a database driving program, and belongs to the technical field of database migration. The problem that in the prior art, comprehensive compatibility of Oracle characteristics is difficult to achieve on the driver level is solved. Comprising the following steps: when a database is in an Oracle compatible mode, receiving a calling statement in an Oracle form at a driving layer; in the SQL statement generation and execution stage, a corresponding grammar conversion strategy is determined according to the type of a calling statement; based on a grammar conversion strategy, performing grammar conversion on the calling statement to obtain a statement supported by a target database kernel, and sending the statement to the target database kernel; in the stage of obtaining the result set, the result set returned by the kernel of the target database is analyzed, and a function return value and / or an out parameter value obtained through analysis are / is transmitted to a corresponding binding variable, so that compatibility of an Oracle function, a storage process and an anonymous block is achieved.

Description

Technical Field

[0001] This application relates to the technical field of database migration, and particularly to an Oracle compatibility method and device based on a database driver. Background Art

[0002] With the advancement of enterprise digital transformation, the demand for database migration is increasing day by day, and the migration scenario from an Oracle database to a PostgreSQL-derived database is particularly common.

[0003] However, there are significant differences in the syntax implementations of key functions such as stored procedures, functions, and anonymous blocks between Oracle and PostgreSQL. Similarly, there are also significant differences in the implementations of the Oracle ODBC driver and the PostgreSQL ODBC driver, which respectively parse the execution commands of the application program into the syntax recognizable by the corresponding database. As the target database, the PostgreSQL-derived database has achieved compatibility with Oracle-related functions at the kernel level. If the corresponding Oracle syntax parsing of the driver program is not compatibly transformed, it will be difficult for the target database kernel to recognize the parsed syntax. At this time, the application program needs to modify a large amount of code to be compatible with the target database. Secondly, due to the lack of support for functions, stored procedures, and anonymous blocks, the business logic needs to be rewritten after migration, which destroys the code consistency.

[0004] In the prior art, the method of relying mainly on manual code refactoring is used to solve the compatibility problem between Oracle and PostgreSQL, but its efficiency is low and it is difficult to cope with large-scale code migration. At present, although some database drivers have achieved Oracle feature compatibility, their database driver programs are mostly designed for specific databases and have limited support for Oracle features, and it is still difficult to achieve comprehensive compatibility with Oracle features at the driver level. Summary of the Invention

[0005] The embodiments of this application provide an Oracle compatibility method and device based on a database driver to solve the following technical problems: Although the drivers of existing databases have achieved Oracle feature compatibility, their database driver programs are mostly designed for specific databases and have limited support for Oracle features, and it is still difficult to achieve comprehensive compatibility with Oracle features at the driver level.

[0006] The embodiments of this application adopt the following technical solutions: An embodiment of this application provides an Oracle compatibility method based on a database driver. The method includes: when the database is in the Oracle compatibility mode, receiving a call statement in Oracle form at the driver layer; at the stage of generating and executing the SQL statement, determining a corresponding syntax conversion strategy according to the type of the call statement; where the call statement includes a function call statement, a stored procedure call statement, and an anonymous block call statement; based on the syntax conversion strategy, performing syntax conversion on the call statement to obtain a statement supported by the target database kernel, and sending it to the target database kernel; at the stage of obtaining the result set, parsing the result set returned by the target database kernel, and passing the function return value and / or out parameter value obtained by parsing to the corresponding binding variable to achieve compatibility with Oracle functions, stored procedures, and anonymous blocks.

[0007] In the embodiment of this application, the driver layer automatically identifies the call statement in Oracle form and converts it into the syntax supported by the target database kernel, so that it can run directly without modifying the native Oracle syntax code, reducing the migration workload. Secondly, for the key differences such as the return value position of the Oracle function, the out parameter passing of the stored procedure, and the anonymous block mode recognition, the driver layer automatically adjusts the parameter order through configuration parameters and performs bitwise operation processing on the variable type identifier to ensure that the target database kernel accurately identifies the function prototype and parameter mode, avoiding execution errors caused by type mismatch in the traditional driver. And developers do not need to learn the PostgreSQL syntax separately, reducing the learning cost, reducing adaptation problems, and shortening the migration cycle.

[0008] In an implementation manner of this application, based on the syntax conversion strategy, performing syntax conversion on the call statement to obtain a statement supported by the target database kernel, specifically including: when the call statement is a function call statement, adjusting the configuration parameters of the target database kernel according to the parameter placeholder information corresponding to the function call statement to determine the placement position of the function return value; using the function return value as an output parameter and reorganizing it with the input parameters into a parameter placement sequence supported by the target database; based on the parameter placement sequence, converting the function call statement into the form of a SELECT statement to obtain the statement supported by the target database kernel corresponding to the function call statement.

[0009] In an implementation manner of the present application, according to the parameter placeholder information corresponding to the function call statement, the configuration parameters of the target database kernel are adjusted to determine the placement position of the function return value, specifically including: according to the type and form of the parameter placeholder corresponding to the function call statement; based on the type and form, adjust the configuration parameter result_first of the target database kernel to true, so as to place the function return value as an out parameter at the first position of the parameters; or, adjust the configuration parameter result_first of the target database kernel to false, so as to place the function return value as an out parameter at the last position of the parameters.

[0010] In an implementation manner of the present application, before obtaining the statement supported by the target database kernel corresponding to the function call statement, the method further includes: binding a type identifier to each parameter; wherein, the type identifier of the output parameter is the same as the type identifier of the function return value.

[0011] In an implementation manner of the present application, based on the syntax conversion strategy, the call statement is syntactically converted to obtain the statement supported by the target database kernel, specifically including: in the case where the call statement is a stored procedure call statement, based on the composition characteristics of the stored procedure call statement, it is divided into a statement that does not need to be converted and a statement that needs to be converted; wherein, the composition characteristics of the statement include specific parentheses and parameter placeholder information; based on the syntax conversion strategies corresponding to the statement that does not need to be converted and the statement that needs to be converted respectively, the call statement is syntactically converted to obtain the statement supported by the target database kernel.

[0012] In an implementation manner of the present application, based on the syntax conversion strategies corresponding to the statement that does not need to be converted and the statement that needs to be converted respectively, the call statement is syntactically converted, specifically including: in the case of belonging to the statement that does not need to be converted, keep the original syntax structure of the stored procedure call statement unchanged; in the case of belonging to the statement that needs to be converted, adjust the specific parentheses of the stored procedure call statement, and keep the parameter placement sequence and bound variables within the specific parentheses unchanged.

[0013] In an implementation manner of the present application, based on the syntax conversion strategy, the call statement is syntactically converted to obtain the statement supported by the target database kernel, specifically including: in the case where the call statement is an anonymous block call statement, perform a preset keyword detection on the SQL statement to determine the real anonymous block; based on the real anonymous block, convert the corresponding SQL statement to the do+using syntax; wherein, the do+using syntax includes a code block and a parameter mode; perform a bitwise operation on the variable type identifier according to the input / output mode of the parameter to achieve mode differentiation; wherein, the parameter mode corresponds to the number of variables and the variable mode, so that the output parameter in the real anonymous block is passed out.

[0014] In an implementation of the present application, bitwise operations are performed on the variable type identifier to achieve mode differentiation, specifically including: adding a variable type identifier to the parameter information structure; performing bitwise calculations on the variable type identifier with different hexadecimals to distinguish modes; where the modes include in mode, out mode, and inout mode.

[0015] In an implementation of the present application, the parsed function return value and / or out parameter value are passed to the corresponding bound variable, specifically including: when executing a function call statement or a stored procedure call statement, by parsing the record returned by the target database kernel, obtaining the return value and the out parameter value, and passing the return value and the out parameter value to the corresponding bound variable; when executing an anonymous block call statement, by parsing the record returned by the target database kernel, obtaining the out parameter value, and passing the out parameter value to the corresponding bound variable.

[0016] An Oracle-compatible device based on a database driver provided by an embodiment of the present application includes: at least one processor; and a memory communicatively connected to the at least one processor; where the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to: when the database is in the Oracle-compatible mode, receive an Oracle-formatted call statement at the driver layer; in the stage of generating and executing an SQL statement, determine a corresponding syntax conversion strategy according to the type of the call statement; where the call statement includes a function call statement, a stored procedure call statement, and an anonymous block call statement; based on the syntax conversion strategy, perform syntax conversion on the call statement to obtain a statement supported by the target database kernel, and send it to the target database kernel; in the stage of obtaining a result set, parse the result set returned by the target database kernel, and pass the parsed function return value and / or out parameter value to the corresponding bound variable to achieve compatibility with Oracle functions, stored procedures, and anonymous blocks.

[0017] The above at least one technical solution adopted in the embodiments of the present application can achieve the following beneficial effects: In the embodiments of the present application, the driver layer automatically identifies Oracle-style call statements and converts them into the syntax supported by the target database kernel, so that they can be directly run without modifying the native Oracle syntax code, reducing the migration workload. Secondly, for key differences such as the return value position of Oracle functions, the passing of out parameters of stored procedures, and the recognition of anonymous block modes, the driver layer automatically adjusts the parameter order through configuration parameters and performs bitwise operation processing on variable type identifiers to ensure that the target database kernel accurately recognizes the function prototype and parameter mode, avoiding execution errors caused by type mismatches in traditional drivers. Moreover, developers do not need to learn PostgreSQL syntax separately, reducing the learning cost, reducing adaptation problems, and shortening the migration cycle. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments recorded in the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings. In the drawings: Figure 1 FIG. is a flowchart of a driver layer processing provided by an embodiment of the present application; Figure 2 FIG. is a flowchart of an Oracle compatibility method based on a database driver provided by an embodiment of the present application; Figure 3 FIG. is a schematic structural diagram of an Oracle compatibility device based on a database driver provided by an embodiment of the present application.

[0019] Reference numerals: 200: Oracle compatibility device based on a database driver, 201: processor, 202: memory. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0020] The embodiments of the present application provide an Oracle compatibility method and device based on a database driver.

[0021] In order to enable those skilled in the art to better understand the technical solutions in the present application, the following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments of this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0022] The technical solutions proposed in the embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0023] The Open Database Connectivity (ODBC) interface is a C programming language interface that enables an application to access data from various database management systems (DBMSs). The ODBC architecture has four main components: Application: Performs processing and calls ODBC functions to submit SQL statements and retrieve results.

[0024] Driver Manager: Loads and unloads drivers on behalf of the application, processes ODBC function calls, or passes them to the driver.

[0025] Driver: Processes ODBC function calls, submits SQL requests to a specific data source, and returns the results to the application.

[0026] Data Source: The specific data that the user wants to access and its associated operating system.

[0027] The psqlODBC driver belongs to the "driver" component in the ODBC architecture and is a driver specific to the Postgresql database. In the embodiments of the present application, syntax and function compatibility transformations are performed on Oracle functions, stored procedures, and anonymous blocks based on the psqlODBC driver. Figure 1 The following is a processing flow chart of the driver layer provided for the embodiments of the present application. As Figure 1 shown, the basic processing flow of the driver layer includes: Connect to the data source: Allocate an environment handle and a connection handle, and connect to the Oracle compatibility mode of the target database; Initialize the application: Allocate a statement handle, set statement attributes, etc.; Generate and execute an SQL statement: After generating an SQL statement and binding any parameters, directly execute the statement, or first prepare the statement and then execute it; Obtain the result set: If it is a query statement or a catalog function, retrieve the data row by row. If it is an insert, update, or delete statement, obtain the number of affected rows; Commit the transaction: When the transaction commit mode is set to manual commit, then execute the commit transaction; Disconnect from the data source: Release the statement handle, disconnect the database link, and release the connection handle and the environment handle.

[0028] Among them, in the embodiments of the present application, the driver layer mainly modifies the compatible functions and syntax of Oracle functions, stored procedures, and anonymous blocks in the parts of "generating and executing SQL statements" and "obtaining result sets".

[0029] Figure 2 The flowchart of an Oracle compatibility method provided for the embodiments of the present application based on a database driver is as Figure 2 shown. The Oracle compatibility method based on the database driver includes the following steps: Step 101: When the database is in the Oracle compatibility mode, receive an Oracle-formatted call statement in the driver layer.

[0030] In an implementation manner of the present application, by setting database parameters, the driver enables the Oracle compatibility mode and triggers the special processing logic for Oracle syntax. In this mode, the driver will actively identify and convert Oracle-specific call statements.

[0031] Step 102: In the stage of generating and executing SQL statements, determine the corresponding syntax conversion strategy according to the type of the call statement.

[0032] In an implementation manner of the present application, the driver divides the call statement into three categories by analyzing the structural characteristics of the statement: function call statement, stored procedure call statement, and anonymous block call statement.

[0033] Function call statement: The feature is that it contains a return value binding, such as {? = call function} or call... into structure, and is used to execute a function with a return value.

[0034] Stored procedure call statement: Starts with the call keyword and can be wrapped in curly braces, such as { call procedure}, and is used to execute a stored procedure without a return value.

[0035] Anonymous block call statement: Starts with BEGIN and ends with END, contains variable declarations and composite logic, and is used to execute a complete PL / SQL code block.

[0036] Determine the corresponding syntax conversion strategy based on the type of different call statements. The driver realizes a high degree of compatibility with Oracle PL / SQL syntax without modifying or minimally modifying the application program, reducing the technical threshold and cost of database migration.

[0037] Step 103: Based on the syntax conversion strategy, perform syntax conversion on the call statement to obtain a statement supported by the target database kernel, and send it to the target database kernel.

[0038] In an implementation of this application, when the call statement is a function call statement, the configuration parameters of the target database kernel are adjusted according to the parameter placeholder information corresponding to the function call statement to determine the position where the function return value is placed. The function return value is used as an output parameter and recombined with the input parameters into a parameter placement sequence supported by the target database. Based on the parameter placement sequence, the function call statement is converted into the form of a SELECT statement to obtain a statement supported by the target database kernel corresponding to the function call statement.

[0039] Specifically, when the call statement is a function call statement, the driver needs to dynamically adjust the database configuration according to the parameter placeholder information, recombine the parameter order, and convert it into a SELECT statement supported by the target database. Specifically, the type and form of the parameter placeholder corresponding to the function call statement are determined. Based on the type and form, the configuration parameter result_first of the target database kernel is adjusted to true to place the function return value as an out parameter at the beginning of the parameters. Alternatively, the configuration parameter result_first of the target database kernel is adjusted to false to place the function return value as an out parameter at the end of the parameters.

[0040] The following is an example to illustrate the syntax conversion of the function call statement. It should be noted that the names of the following functions and stored procedures are replaced by function and procedure. In the actual application process, the specific defined function and stored procedure names are used, and the number of parameters is indefinite. It can be one, multiple, or no parameters: (1) For the function call in the form of a question mark placeholder {? = call function(?, ?,?)}, the driver will convert it into the form of a SELECT statement and place the function return value as an out parameter at the beginning of the parameters. Among them, there is a configuration parameter result_first in the database kernel, which defaults to true, that is, the return value is placed at the beginning. That is, it is equivalent to the above example function having four parameters, and the converted SELECT statement form is SELECT * FROM function(?,?,?,?), where the first question mark is the return value. The parameter type identifier id is the same as the parameter type identifier id of the out parameter. The driver will send this statement to the database kernel, and the database kernel can recognize the function prototype according to the parameter type.

[0041] (2)For function calls in the form of colon-bound variables {:ret = call function(:1,:2,:3)}, the driver enhances the recognition of colon placeholder variables and converts them into a SELECT statement in the form of SELECT * FROM function(:ret, :1, :2, :3).

[0042] Specifically, through the {:ret = call...} structure, it is determined that :ret is the bound variable for the function return value. The colon variables in the parameter list are extracted and used as placeholders for input parameters. The driver adjusts the database kernel parameter result_first=true to indicate that the return value should be placed at the beginning of the parameter list. The driver converts the colon-bound call in Oracle into a SELECT statement supported by the target database. The colon variables are arranged in the order of [return value, input parameter 1, input parameter 2,...] to ensure consistency with the Oracle call semantics. Type information is bound to each colon variable to ensure that the type of the return value :ret matches the return type defined by the function and also to ensure that the types of the input parameters match the parameter types defined by the function in sequence.

[0043] Furthermore, when the converted SELECT statement is passed to the target database kernel, the kernel checks whether the total number of parameters is consistent with the function definition. Through the type identifiers of the colon variables, the kernel verifies whether the parameter types match the function prototype. After executing the function, the kernel passes the return value to the driver through the :ret variable, and the driver then maps it to the bound variable of the application.

[0044] (3)For function calls in the form of call function(?, ?, ?) into?, the driver will convert them into a SELECT statement form and place the function return value as an out parameter at the end of the parameters (while setting the configuration parameter result_first to false, i.e., the return value is placed at the end). The converted SELECT statement form is SELECT * FROM function(?, ?, ?, ?), where the last question mark is the return value, which is sent to the database kernel, and the kernel can identify the function prototype based on the parameter types.

[0045] Specifically, through the call... into? structure, the last question mark is recognized as the placeholder for the function return value. The question mark placeholder between call and into is extracted and determined as the input parameter of the function. The total number of input parameter and return value placeholders is counted. For example, call func(?, ?, ?) into? involves a total of 4 parameters. The driver controls the position of the return value by adjusting the result_first parameter of the database kernel, that is, setting result_first to false indicates that the return value should be placed at the end of the parameter list, the input parameters are arranged in the original order in the front, and the return value is used as the last parameter to form a parameter sequence of [input parameter 1, input parameter 2,..., return value]. The driver converts the corresponding function call in Oracle into a SELECT statement supported by the target database. Type information is bound to each question mark placeholder to ensure that the type identifier of the return value is consistent with the return type defined by the function, and the type identifiers of the input parameters match the parameter types defined by the function in order.

[0046] In an implementation manner of this application, when the call statement is a stored procedure call statement, based on the composition characteristics of the stored procedure call statement, it is divided into a statement that does not need to be converted and a statement that needs to be converted; wherein, the composition characteristics of the statement include specific parentheses and parameter placeholder information. Based on the corresponding syntax conversion strategies for the statement that does not need to be converted and the statement that needs to be converted, the call statement is subjected to syntax conversion to obtain a statement supported by the target database kernel.

[0047] Specifically, in the case of a statement that does not need to be converted, the original syntax structure of the stored procedure call statement remains unchanged. In the case of a statement that needs to be converted, the specific parentheses of the stored procedure call statement are adjusted, and the parameter placement sequence and bound variables within the specific parentheses are kept unchanged.

[0048] Specifically, the following is an illustrative example of the syntax conversion of the stored procedure call statement: For the stored procedure call in the standard ODBC form of { call procedure(?, ?, ?)}, the driver directly removes the curly braces, and the content within the curly braces remains unchanged and is sent to the database kernel, and the kernel can recognize the CALL syntax of the stored procedure. For the stored procedure call in the form of call procedure(:1, :2) with colon-bound variables, the driver does not perform any conversion and sends it to the database kernel as it is, and the kernel can recognize the CALL syntax of the stored procedure.

[0049] In an implementation of the present application, in the case where the call statement is an anonymous block call statement, the SQL statement is detected for preset keywords to determine the true anonymous block. Based on the true anonymous block, the corresponding SQL statement is converted into the do+using syntax; wherein, the do+using syntax includes a code block and a parameter mode. According to the input / output mode of the parameter, bitwise operation processing is performed on the variable type identifier to achieve mode differentiation. Among them, the parameter mode corresponds to both the number of variables and the variable mode, so that the output parameters in the true anonymous block are passed out.

[0050] Specifically, for all Oracle call forms of anonymous blocks, it is first necessary to determine whether the SQL statement is a true anonymous block call or an ordinary transaction block. Specifically, the entire SQL statement is treated as a string, the comment part and whitespace characters at the beginning are skipped, and the remaining string is judged as follows: 1. If it starts with "DECLARE", it can be determined as an anonymous block; 2. If it starts with "BEGIN" and there is a matching "END", and the statement contains the transaction control statements "COMMIT" or "ROLLBACK", it is a transaction block, otherwise it is an anonymous block.

[0051] Further, after determining that it is an anonymous block, the SQL statement is converted into the do+using syntax, and for the variables in the anonymous block, according to different modes, the variable type identifier Oid needs to perform a bitwise OR calculation with different hexadecimals to distinguish different modes. That is, the anonymous block in the Oracle syntax is converted into the do+using syntax, and the data type of the parameter is added to the parameter information structure body, and by performing a bitwise OR calculation with different hexadecimals, the in / out / inout modes of the parameters can be distinguished by the database kernel. This syntax allows the bound out variables in the anonymous block to be passed out. Step 104, in the stage of obtaining the result set, the result set returned by the target database kernel is parsed, and the function return value and / or out parameter value obtained by parsing are passed to the corresponding bound variables to achieve compatibility with Oracle functions, stored procedures, and anonymous blocks.

[0052] In an implementation of the present application, when executing a function call statement or a stored procedure call statement, the record returned by the target database kernel is parsed to obtain the return value and the out parameter value, and the return value and the out parameter value are passed to the corresponding bound variables. When executing an anonymous block call statement, the record returned by the target database kernel is parsed to obtain the out parameter value, and the out parameter value is passed to the corresponding bound variable.

[0053] Specifically, for the calls to Oracle functions and stored procedures, when obtaining the result set, the process of obtaining the result set is enhanced. In the result set, the kernel will combine the function return value with other out parameters to form a record for return. The driver will parse the record and pass the return value and the out parameter values to the corresponding bound variables. For the calls to Oracle anonymous blocks, if there are out parameters in the anonymous block, the kernel will combine all the out parameters to form a record for return, and the driver will parse the record and pass the out parameter values to the corresponding bound variables.

[0054] In the embodiments of this application, the psqlODBC driver receives the corresponding Oracle functions, stored procedures, and anonymous blocks, converts the syntax into the syntax supported by the database kernel in the "Generate and Execute SQL Statements" section, and passes the return value and the out parameters (if any) to the corresponding bound variables in the "Obtain Result Set" section, thereby achieving compatibility with Oracle functions, stored procedures, and anonymous blocks.

[0055] There are differences between the traditional Oracle PL / SQL syntax and the PostgreSQL PL / pgSQL, resulting in a large amount of code rewriting required for migration. The embodiments of this application automatically perform conversion at the driver layer, reducing the amount of modification to the customer application, and even eliminating the need for modification, thus reducing the development cost. Secondly, the embodiments of this application adapt the Oracle syntax logic at the driver layer, and the application can directly execute Oracle-style functions, stored procedures, and anonymous blocks. The embodiments of this application enable developers to avoid learning the PostgreSQL syntax separately, reducing the learning cost. It reduces adaptation issues and shortens the migration cycle.

[0056] Figure 3 It is a schematic structural diagram of an Oracle-compatible device provided by the embodiments of this application. As Figure 3As shown, the Oracle-compatible device 200 based on a database driver includes: at least one processor 201; and a memory 202 communicatively connected to the at least one processor 201; wherein the memory 202 stores instructions executable by the at least one processor 201, and the instructions are executed by the at least one processor 201 to enable the at least one processor 201 to: receive an Oracle-formatted call statement at the driver layer when the database is in Oracle-compatible mode; determine a corresponding syntax conversion strategy according to the type of the call statement during the stage of generating and executing an SQL statement; wherein the call statement includes a function call statement, a stored procedure call statement, and an anonymous block call statement; perform syntax conversion on the call statement based on the syntax conversion strategy to obtain a statement supported by the target database kernel, and send it to the target database kernel; during the stage of obtaining a result set, parse the result set returned by the target database kernel, and pass the parsed function return value and / or out parameter value to the corresponding bind variable to achieve compatibility with Oracle functions, stored procedures, and anonymous blocks.

[0057] The embodiments in the present application are all described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the embodiments of the apparatus, device, and non-volatile computer storage medium, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can refer to the partial description of the method embodiments.

[0058] The above description is only for the embodiments of the present application and is not intended to limit the present application. For those skilled in the art, various changes and modifications can be made to the embodiments of the present application. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. An Oracle compatibility method based on a database driver, characterized in that, The method includes: When the database is in Oracle compatibility mode, receiving a call statement in Oracle form at the driver layer; In the stage of generating and executing the SQL statement, determining the corresponding syntax conversion strategy according to the type of the call statement; wherein, the call statement includes a function call statement, a stored procedure call statement, and an anonymous block call statement; Based on the syntax conversion strategy, performing syntax conversion on the call statement to obtain a statement supported by the target database kernel, and sending it to the target database kernel; in the stage of obtaining the result set, parsing the result set returned by the target database kernel, and passing the function return value and / or out parameter value obtained by parsing to the corresponding bound variable to achieve compatibility with Oracle functions, stored procedures, and anonymous blocks.

2. The Oracle compatibility method based on a database driver according to claim 1, wherein The performing syntax conversion on the call statement based on the syntax conversion strategy to obtain a statement supported by the target database kernel specifically includes: When the call statement is the function call statement, adjusting the configuration parameters of the target database kernel according to the parameter placeholder information corresponding to the function call statement to determine the position where the function return value is placed; Taking the function return value as an output parameter and recombining it with the input parameters into a parameter placement sequence supported by the target database; Based on the parameter placement sequence, converting the function call statement into a SELECT statement form to obtain a statement supported by the target database kernel corresponding to the function call statement.

3. The Oracle compatibility method based on a database driver according to claim 2, wherein, The adjusting the configuration parameters of the target database kernel according to the parameter placeholder information corresponding to the function call statement to determine the position where the function return value is placed specifically includes: Determining the type and form of the parameter placeholder corresponding to the function call statement; Based on the type and form, adjusting the configuration parameter result_first of the target database kernel to true to place the function return value as an out parameter at the beginning of the parameters; Or, adjusting the configuration parameter result_first of the target database kernel to false to place the function return value as an out parameter at the end of the parameters.

4. The Oracle compatibility method based on a database driver according to claim 2, characterized in that, Before obtaining the statement supported by the target database kernel corresponding to the function call statement, the method further includes: Binding a type identifier to each parameter; Wherein, the type identifier of the output parameter is the same as the type identifier of the function return value.

5. A method for Oracle compatibility based on a database driver according to claim 1, wherein, The performing syntax conversion on the call statement based on the syntax conversion strategy to obtain a statement supported by the target database kernel specifically includes: When the call statement is the stored procedure call statement, based on the composition characteristics of the stored procedure call statement, dividing it into a statement that does not need to be converted and a statement that needs to be converted; wherein, the composition characteristics of the statement include specific parentheses and parameter placeholder information; Based on the syntax conversion strategies corresponding to the statement that does not need to be converted and the statement that needs to be converted respectively, performing syntax conversion on the call statement to obtain a statement supported by the target database kernel.

6. The Oracle compatibility method based on a database driver according to claim 5, wherein Performing syntax conversion on the call statement based on the syntax conversion strategies respectively corresponding to the statements that do not need to be converted and the statements that need to be converted, specifically including: In the case of a statement that does not need to be converted, keeping the original syntax structure of the stored procedure call statement unchanged; In the case of a statement that needs to be converted, adjusting the specific parentheses of the stored procedure call statement and keeping the parameter placement sequence and bound variables within the specific parentheses unchanged.

7. A method for Oracle compatibility based on a database driver according to claim 1, characterized in that, Performing syntax conversion on the call statement based on the syntax conversion strategy to obtain a statement supported by the target database kernel, specifically including: In the case where the call statement is an anonymous block call statement, performing a preset keyword detection on the SQL statement to determine the real anonymous block; Based on the real anonymous block, converting the corresponding SQL statement into a do+using syntax; wherein, the do+using syntax includes a code block and a parameter mode; performing a bitwise operation on the variable type identifier according to the input / output mode of the parameter to achieve mode differentiation; wherein, the parameter mode corresponds to the number of variables and the variable mode, so that the output parameters in the real anonymous block are passed out.

8. An Oracle compatibility method based on a database driver according to claim 7, characterized in that, The performing of bitwise operation on the variable type identifier to achieve mode differentiation specifically includes: Adding a variable type identifier to the parameter information structure; Performing a bitwise calculation of the variable type identifier with different hexadecimals for mode differentiation; wherein, the modes include in mode, out mode, and inout mode.

9. A method for Oracle compatibility based on a database driver according to claim 1, characterized in that, The passing of the function return value and / or out parameter value obtained by parsing to the corresponding bound variable specifically includes: When executing the function call statement or the stored procedure call statement, parsing the record returned by the target database kernel to obtain the return value and the out parameter value, and passing the return value and the out parameter value to the corresponding bound variable; When executing the anonymous block call statement, parsing the record returned by the target database kernel to obtain the out parameter value, and passing the out parameter value to the corresponding bound variable.

10. An Oracle-compatible device based on a database driver, characterized in that, The device includes a memory for storing computer program instructions and a processor for executing the program instructions. Wherein, when the computer program instructions are executed by the processor, the device is triggered to execute the method according to any one of claims 1-9.

Images