Methods, devices, computer equipment, and program products for obtaining SQL statements

Abstract

This application discloses a method, apparatus, computer device, and program product for obtaining SQL statements, relating to the field of databases. In this application, static analysis of the application's source code is used to locate code segments containing SQL keywords to be processed. Based on this, test cases are generated using the identified code segments, and the test cases are executed to obtain the SQL statements generated during the execution of the test cases. Therefore, this application combines static and dynamic analysis to extract SQL statements from the application's source code. Static analysis of the source code allows for the comprehensive location of code segments containing SQL statements. Dynamic analysis, using test cases corresponding to these code segments, yields complete and accurate SQL statements.

Description

Technical Field

[0001] This application relates to the field of databases, and more particularly to a method, apparatus, computer device, and program product for obtaining Structured Query Language (SQL) statements. Background Technology

[0002] SQL is a standard language for managing and manipulating relational databases. SQL statements can be used to perform various database operations such as defining database objects, adding, deleting, modifying, and querying data.

[0003] Currently, in certain scenarios, it may be necessary to extract SQL statements from applications running on a database. For example, in a database migration scenario, for an application running on a first database, the SQL statements can be extracted and modified according to the SQL syntax of a second database to ensure compatibility, thus enabling the application to run on the second database. As another example, to ensure database security, SQL statements from applications running on that database can be extracted and analyzed to identify risky SQL statements. In such scenarios, how to extract more accurate and comprehensive SQL statements from the application is a pressing problem that needs to be solved. Summary of the Invention

[0004] This application provides a method, apparatus, computer device, and program product for obtaining SQL statements, which can extract SQL statements from applications as comprehensively as possible, and the extracted SQL statements are accurate and complete.

[0005] To achieve the above objectives, this application adopts the following technical solution:

[0006] In a first aspect, a method for obtaining SQL statements is provided, the method comprising: performing static analysis on the source code of an application to obtain multiple code segments to be processed, each code segment containing SQL keywords; generating test cases based on at least one of the multiple code segments; executing the test cases and obtaining the SQL statements generated during the execution of the test cases.

[0007] In this application, static analysis of the application's source code is used to locate code segments containing SQL keywords. Based on this, test cases are generated using the identified code segments and executed to obtain the SQL statements generated during test case execution. Therefore, this application combines static and dynamic analysis to extract SQL statements from the application's source code. Static analysis allows for the comprehensive location of code segments containing SQL statements. Dynamic analysis, using test cases corresponding to these code segments, yields complete and accurate SQL statements.

[0008] Optionally, the method further includes: extracting SQL statements from each of the plurality of code segments; and on this basis, the implementation process of generating test cases based on at least one of the plurality of code segments may include: generating corresponding test cases based on the at least one code segment from which SQL statement extraction failed.

[0009] In this application, for multiple code segments containing SQL keywords, static analysis can be performed on each segment to extract the SQL statements. Based on this, for successfully extracted code segments, it is unnecessary to generate test cases to obtain the SQL statements; for code segments where extraction fails, test cases are generated to obtain the SQL statements. This reduces server resource consumption.

[0010] Optionally, the process of extracting SQL statements from each of the plurality of code segments may include: parsing the code statements in the first code segment of the plurality of code segments to obtain an initial SQL statement; detecting whether there is a target variable whose variable value needs to be completed in the initial SQL statement; based on the detection that there is a target variable whose variable value needs to be completed in the initial SQL statement, using the data definition language (DDL) file corresponding to the source code to obtain the variable value of the target variable; based on the failure to obtain the variable value of the target variable, determining that the first code segment is a code segment in which SQL statement extraction failed, or, based on the obtained variable value of the target variable, using the variable value of the target variable to complete the initial SQL statement, and determining the completed SQL statement as the SQL statement successfully extracted from the first code segment.

[0011] In this application, during the static analysis of each code segment to extract SQL statements, if the extracted initial SQL statement contains target variables whose values ​​need to be completed, a DDL file can be used to obtain the values ​​of these target variables. Since the DDL file contains data table information, the probability of finding the data type of the target variable using the DDL file is relatively high. Based on this, the probability of successfully obtaining the variable values ​​and completing the SQL statement using the DDL file is also relatively high. Therefore, using a DDL file to complete SQL statements has a high success rate, which is beneficial for obtaining complete SQL statements.

[0012] Optionally, the process of obtaining the variable value of the target variable based on the DDL file corresponding to the source code may include: obtaining data table information in a first database based on the DDL file, wherein the first database is the database used by the source code during runtime; searching for the data type of the target column corresponding to the target variable in the data table information; generating the variable value of the target variable based on the data type of the target column found, or determining that the variable value of the target variable has not been obtained based on the data type of the target column not being found.

[0013] In this application, the data type of the target column corresponding to the target variable is found in the data table information. Based on the data type of the target column found, a variable value of the corresponding type can be generated. This variable value is used to complete the SQL statement, which solves the problem of incomplete SQL statements due to the lack of user input during static analysis.

[0014] Optionally, the at least one code segment includes a second code segment, and the step of generating test cases based on at least one of the plurality of code segments includes: determining the initial calling function on the function call chain where the target function containing the SQL statement in the second code segment is located; and generating test cases corresponding to the second code segment based on the initial calling function.

[0015] The test cases include an initial calling function. By analyzing the function call chain of the target function containing the SQL statement, the initial calling function at the top of the chain can be identified. Based on this, test cases are constructed using this initial calling function. Subsequently, when the test cases are executed, this initial calling function is called. The initial calling function then calls the next function in the function call chain, and so on, until the function executing the SQL statement is reached, at which point it generates the SQL statement. This process yields the SQL statement.

[0016] Optionally, the source code is source code adapted to the first database, and the method further includes: detecting whether the first SQL statement is adapted to the second database, wherein the second database is different from the first database, and the first SQL statement is an SQL statement obtained during the execution of the test case or an SQL statement successfully extracted from other code segments besides the at least one code segment; if the first SQL statement is not adapted to the second database, then the first SQL statement is converted to obtain a second SQL statement, wherein the second SQL statement is an SQL statement adapted to the second database.

[0017] In this application, the application's source code can be adapted to the first database, meaning the application can run on the first database. When the application needs to migrate from the first database to the second database, after obtaining the SQL statements in the source code, it can also check whether the obtained SQL statements are compatible with the second database. If they are not compatible, the obtained SQL statements can be converted to make the converted SQL statements compatible with the second database. This application uses a combination of static and dynamic analysis to obtain the SQL statements in the source code more comprehensively and accurately. Based on this, it can automatically convert as many SQL statements in the source code as possible that are incompatible with the second database, reducing the workload required for manual extraction and conversion due to incomplete or inaccurate SQL statements, thus improving database migration efficiency.

[0018] Optionally, after converting the first SQL statement in the obtained source code, the method further includes: modifying a third code segment in the source code containing the first SQL statement based on the second SQL statement, wherein the modified third code segment contains the second SQL statement.

[0019] Because this application relies on source code to locate the code segment containing SQL statements, and then obtains the SQL statements through static or dynamic analysis of the code segment, it can automatically locate the position of any SQL statement in the obtained source code. Thus, the source code can be automatically modified based on the converted SQL statement, realizing automatic adaptation and modification of the source code. This reduces the difficulty of migrating the application source code during database migration, reduces the migration workload, and improves the efficiency of database migration.

[0020] Optionally, the second SQL statement is obtained by converting the first SQL statement based on the SQL conversion rule base. The method further includes: displaying the first SQL statement and the second SQL statement; obtaining the modified second SQL statement in response to the user's modification operation on the second SQL statement; and updating the SQL conversion rule base based on the first SQL statement and the modified second SQL statement.

[0021] In this application, the converted SQL statement can be modified by the user. Based on the user-modified SQL statement and the corresponding original SQL statement in the source code, new conversion rules are generated to continuously update the SQL conversion rule base. This helps to improve the accuracy of subsequent SQL statement conversions.

[0022] Optionally, the method further includes: displaying the source code marked with SQL statements for a user to view.

[0023] Secondly, a method for obtaining SQL statements is provided, the method comprising: performing static analysis on the source code of an application to obtain multiple code segments to be processed, each code segment including SQL keywords; parsing the code statements in each code segment to obtain an initial SQL statement; and, if there are target variables in the initial SQL statement whose variable values ​​need to be completed, using the DDL file corresponding to the source code to complete the initial SQL statement.

[0024] In this application, if the initial SQL statement extracted from the code segment through static analysis contains target variables whose variable values ​​need to be completed, the initial SQL statement can be completed using a DDL file, thereby improving the completeness and accuracy of the obtained SQL statement.

[0025] Optionally, the process of completing the initial SQL statement using the DDL file corresponding to the source code may include: obtaining data table information from a first database based on the DDL file, wherein the first database is the database used by the source code during runtime; searching for the data type of the target column corresponding to the target variable in the data table information; generating the variable value of the target variable based on the found data type of the target column; and completing the initial SQL statement using the variable value of the target variable.

[0026] In this application, the DDL file contains information about each column in the data table when the data table is created, such as the column name and data type of each column. Therefore, the data type of the target column corresponding to the target variable can be found in the data table information contained in the DDL file. Then, based on the data type of the target column found, the corresponding variable value is generated. The variable value is used to complete the SQL statement, which solves the problem of incomplete SQL statements due to the lack of user input during static analysis.

[0027] Optionally, the method further includes: receiving a DDL file, which may be uploaded by a user.

[0028] Thirdly, an apparatus for obtaining SQL statements is provided, the apparatus comprising at least one module for performing the method for obtaining SQL statements as described in the first or second aspect above.

[0029] Fourthly, a computer device is provided, the computer device including a processor, the processor being configured to execute at least one program instruction or code stored in a memory to implement the method for obtaining SQL statements as described in the first or second aspect above.

[0030] Fifthly, a computer-readable storage medium is provided, wherein instructions are stored therein, which, when executed on a computer device, cause the computer device to perform the method for obtaining SQL statements as described in the first or second aspect.

[0031] In a sixth aspect, a computer program product containing instructions is provided, which, when run on a computer device, causes the computer device to execute the method for obtaining SQL statements described in the first or second aspect above.

[0032] The technical effects achieved by the third to sixth aspects mentioned above are similar to those achieved by the corresponding technical means in the first and second aspects, and will not be repeated here. Attached Figure Description

[0033] Figure 1 This is a diagram illustrating an implementation environment for the method of obtaining SQL statements provided in this application.

[0034] Figure 2 A schematic diagram of the structure of a computer device provided in an embodiment of this application;

[0035] Figure 3 A schematic diagram of a service cluster provided for an embodiment of this application;

[0036] Figure 4A flowchart illustrating a method for obtaining SQL statements provided in an embodiment of this application;

[0037] Figure 5 An exemplary flowchart for obtaining an SQL statement is provided as an embodiment of this application;

[0038] Figure 6 This is a schematic diagram illustrating how, in a database migration scenario, the source code of an application adapted to a first database is converted to adapt to a second database.

[0039] Figure 7 A schematic diagram of the structure of an apparatus for obtaining SQL statements provided in an embodiment of this application;

[0040] Figure 8 This is a schematic diagram of another device for obtaining SQL statements provided in an embodiment of this application. Detailed Implementation

[0041] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0042] Before providing a detailed explanation of the embodiments of this application, let's first introduce the application scenarios involved in the embodiments of this application.

[0043] Applications that rely on databases may contain SQL statements, which can be used to manage and manipulate the database.

[0044] Currently, in some scenarios, it is necessary to extract SQL statements from database-based applications and then further process the obtained SQL statements to achieve certain purposes.

[0045] For example, in one possible scenario, considering business needs, operating costs, and other factors, it might be necessary to migrate the first database used by the application to a second database. During database migration, not only must the data in the first database be migrated to the second, but the SQL statements in the application running on the first database also need to be extracted and transformed so that the SQL syntax of the transformed application is compatible with the SQL syntax of the second database, thereby achieving the migration of the application from the first database to the second database.

[0046] In another possible scenario, applications may contain risky SQL statements. Using these risky SQL statements to manipulate the database could lead to database failures, such as corrupting stored data and severely impacting database availability. Therefore, to ensure database security, SQL statements in applications running on the database can be extracted and analyzed to identify risky SQL statements.

[0047] Currently, one related technology involves extracting SQL statements from the application's source code through static analysis. However, since static analysis relies solely on the application's source code and lacks user input parameters, the SQL statements extracted from the source code may contain syntax errors, incomplete statements, and other problems.

[0048] In another related technique, SQL statements in an application can be obtained through dynamic analysis. Specifically, instrumentation can be used to insert target code segments into the database driver to retrieve SQL statements. Based on this, during application runtime, when the application generates corresponding SQL statements based on user input and executes these generated SQL statements through the database driver, the target code segment can obtain the SQL statements to be executed. Therefore, the SQL statements obtained through dynamic analysis are mainly those generated in response to user input. However, during application runtime, only a portion of the SQL statements executed in response to user input are actually executed. For example, some SQL statements in the application may not depend on user input for execution, or the application may not receive certain types of user input during runtime; consequently, SQL statements that depend on such user input will not be executed. This results in a limited number of SQL statements that can be obtained through dynamic analysis.

[0049] To address the problems existing in the aforementioned related technologies, this application provides a method for obtaining SQL statements. This method can be applied to the aforementioned database migration scenario and the scenario of identifying risky SQL statements. In this method, static analysis of the application's source code is used to locate the code segments containing SQL keywords to be processed. Based on this, test cases are generated using the found code segments, and the test cases are executed to obtain the SQL statements generated during the execution of the test cases. Therefore, this application combines static and dynamic analysis to extract SQL statements from the application's source code. By performing static analysis on the source code, code segments containing SQL statements can be located as comprehensively as possible. Based on this, dynamic analysis is performed by generating test cases corresponding to the code segments, resulting in complete and accurate SQL statements.

[0050] The method for obtaining SQL statements provided in this application embodiment can be executed by a server-side device. In this case, see, for example... Figure 1 The server-side device 101 can receive the source code of an application uploaded by the user through the user-side device 102, and use the method provided in this application embodiment to obtain the SQL statements in the application based on the source code of the application.

[0051] Optionally, in this embodiment of the application, the server-side device 101 may also receive the DDL file corresponding to the source code uploaded by the user through the user-side device 102, so as to use the DDL file to complete the target variable of the extracted SQL statement during the static analysis of the source code.

[0052] Optionally, after obtaining the SQL statement, the server-side device 101 can also display the source code marked with the SQL statement through the user-side device 102. For example, the server-side device 101 can send the source code and the position of the SQL statement in the source code to the user-side device 102, so that the user-side device 102 can mark the SQL statement in the source code based on the position of the SQL statement and display the marked source code.

[0053] Optionally, in a database migration scenario, the source code of the application uploaded by the user is source code adapted to the source database, i.e., the first database. Based on this, after obtaining the SQL statement in the application through the method provided in this application embodiment, the server-side device 101 can also convert the obtained SQL statement and modify the source code using the converted SQL statement, so that the modified source code is adapted to the target database to be migrated to, i.e., the second database.

[0054] Optionally, in a database migration scenario, after modifying the source code using the transformed SQL statement, the server-side device 101 can also send the modified source code to the user-side device 102 so that the user-side device 102 can display the modified source code to the user.

[0055] The method for obtaining SQL statements provided in this application embodiment can also be executed by a user-side device. In this case, the user-side device can receive the source code of an application imported by the user and use the method provided in this application embodiment to obtain the SQL statements in the application based on the application's source code.

[0056] Optionally, after obtaining the SQL statement, the user-side device can mark and display the obtained SQL statement in the source code.

[0057] Optionally, in a database migration scenario, the source code of the application imported by the user is source code adapted to the source database, i.e., the first database. Based on this, after obtaining the SQL statements in the application, the user-side device can also convert the obtained SQL statements and use the converted SQL statements to modify the source code, thereby making the modified source code compatible with the target database to be migrated to, i.e., the second database. Optionally, the user-side device can also display the modified source code for the user to view.

[0058] It should be noted that the aforementioned user-side devices can be user terminals such as personal computers, mobile phones, and tablets.

[0059] Furthermore, the functions of the aforementioned service-side device can be implemented by a single server, or by a service cluster containing multiple servers. That is, when the method provided in this embodiment is executed by the service-side device, the method can be executed by a single server or by a service cluster containing multiple servers.

[0060] Figure 2 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The user-side device or server mentioned in this embodiment can... Figure 2 This is implemented using the computer device shown. For example, as... Figure 2 As shown, the computer device may include a processor 201, a memory 202, a communication bus 203, and a communication interface 204. It should be noted that... Figure 2 The illustrated device structure does not constitute a limitation on the computer device. A computer device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. Furthermore, the embodiments of this application do not limit the number of processors 201 and memory 202 included in the computer device 200. The following is in conjunction with… Figure 1 A detailed introduction to each component of a computer device:

[0061] Processor 201 is the control and computing center of the computer device. Processor 201 may include any one or more of the following processors: central processing unit (CPU), graphics processing unit (GPU), neural network processing unit (NPU), microprocessor (MP), digital signal processor (DSP).

[0062] The memory 202 may be a high bandwidth memory (HBM), a read-only memory (ROM), or other type of static storage device capable of storing static information and instructions; a random access memory (RAM), or other type of dynamic storage device capable of storing information and instructions; or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM), or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, or other magnetic storage devices; or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer device, but not limited thereto. The memory 202 may exist independently and be connected to the processor 201 via the communication bus 203. Alternatively, the memory 202 may be integrated with the processor 201.

[0063] It should be noted that the memory 202 stores executable program code, which the processor 201 executes to implement the method for obtaining SQL statements as described in the following embodiments. That is, the memory 202 stores instructions for executing the method for obtaining SQL statements described below. Optionally, the memory 202 may also store data generated during the process of the processor 201 executing the executable program code to implement the method for obtaining SQL statements.

[0064] The communication bus 203 may include a path for transmitting information between various components of the computer device 200. This communication bus 203 may be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 1 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0065] The communication interface 204 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computer device 200 and other devices or communication networks.

[0066] As one embodiment, the computer device may also include output devices and input devices. The output device communicates with the processor 201 and can display information in various ways. For example, the output device may be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector, etc. The input device communicates with the processor 201 and can receive input in various ways. For example, the input device may be a mouse, keyboard, touchscreen device, or sensing device, etc.

[0067] As described above, the method for obtaining SQL statements provided in this application embodiment can also be executed by a service cluster comprising multiple servers. Based on this, this application embodiment also provides a schematic diagram of a service cluster, such as... Figure 3 As shown, this service cluster can include multiple servers ( Figure 3 The image shows three servers (301, 302, and 303), each of which can be accessed via... Figure 2 The computer equipment shown is used to implement this. Furthermore, the multiple servers can be connected via a network to transmit intermediate results generated during the execution of the methods provided in the embodiments of this application. The network can be a wide area network (WAN) or a local area network (LAN), etc.

[0068] It should be noted that the memories of multiple servers in this service cluster may each store partial instructions for executing the method of retrieving SQL statements as described in the following embodiments. In other words, the combination of multiple servers can jointly implement the method of retrieving SQL statements provided in the embodiments of this application.

[0069] For example, such as Figure 3 As shown, servers 301, 302, and 303 store different instructions, each used to implement subsequent operations. Figure 7 or Figure 8 The diagram illustrates the functions of different modules in the apparatus for obtaining SQL statements. For example, server 301 may store information for implementing... Figure 7 or Figure 8 The instructions for implementing the functions of the static analysis module 71 and the dynamic analysis module 72 shown can be stored in the server 302. Figure 8 The instructions for implementing the functions of the statement conversion module 73, code modification module 74, and rule base update module 76 shown in the diagram can be stored in server 303. Figure 8 The instructions for the functions of the user interface module 75 in the middle.

[0070] The method for obtaining SQL statements provided in the embodiments of this application will be described in detail below.

[0071] Figure 4 This document provides a flowchart of a method for obtaining SQL statements according to an embodiment of this application. This method can be executed by the aforementioned server-side device or user-side device. The following description assumes that the method is executed by a server-side device, specifically a single server. For example, as shown... Figure 4 As shown, the method includes the following steps:

[0072] S401: Perform static analysis on the application's source code to obtain multiple code segments to be processed, each containing SQL keywords.

[0073] In this embodiment of the application, the server can receive the source code file of the application uploaded by the user through the user-side device, and search for multiple target literals containing SQL keywords in the source code contained in the source code file. Then, the code segment containing each target literal, which is used to implement a complete specific function, is determined as a code segment to be processed.

[0074] SQL keywords are reserved words used to construct SQL statements and can be used to instruct the execution of specific database operations. For example, SQL keywords may include: `select` to indicate the selection of data from a data table, `update` to indicate the updating of data in a data table, `delete` to indicate the deletion of data in a data table, `insert into` to indicate the insertion of data into a data table, and so on. Since SQL keywords are strings, they can usually be contained within literals. Therefore, in this embodiment, the server can search for target literals containing SQL keywords in the source code to initially locate the position of the SQL statement.

[0075] Since SQL statements in the source code may be composed of multiple SQL statement fragments, and different SQL statement fragments within a single SQL statement may be scattered across different code statements within the method containing the target literal—for example, they may be included in variables, expressions, assignment statements, or function calls within the method containing the target literal—the server can further determine the method containing the target literal after identifying it, and designate that method as the code segment to be processed.

[0076] In one possible implementation, the server can parse the source code in the source code file to obtain the corresponding abstract syntax tree (AST). Then, based on this AST, the server can look up the target literal and determine the method in which the target literal belongs.

[0077] It's important to note that an Abstract Syntax Tree (AST) is a data structure used to describe the source code of a program. An AST consists of multiple nodes and edges. Each node represents a syntactic unit within the source code, and nodes are connected by edges to represent hierarchical or dependency relationships. For example, if a user-uploaded application's source code is Java source code, a node in the AST can represent a class within that source code. The child nodes connected to this node through edges can represent methods within that class. These child nodes can also be connected to other child nodes, representing literals, variables, assignment statements, expressions, and / or functions within that method.

[0078] After obtaining the AST corresponding to the source code, the server can traverse the AST to find the first node representing the literal. Then, the server can check whether the literal represented by each first node contains an SQL keyword. If any literal represented by a first node contains a keyword, then the literal represented by that first node is the target literal. For ease of description, the first node representing the target literal is called the target node. The server can determine the second node representing the method from the ancestor nodes of the target node. The method represented by this second node is the method containing the target literal, that is, the code segment to be processed. The ancestor nodes of the target node include the target node's parent node, the parent node's parent node, and so on.

[0079] S402: Generate test cases based on at least one of multiple code segments.

[0080] As shown in S401, the multiple code segments identified by the server all contain the SQL keyword, meaning that each of these code segments contains SQL statements. Based on this, the server can generate test cases based on at least one of these code segments, and then dynamically obtain the SQL statements contained in that at least one code segment through S403.

[0081] In one possible implementation, after receiving multiple code segments to be processed, the server first extracts SQL statements from each of these segments through static analysis. Based on this, the server can generate corresponding test cases based on at least one code segment from which SQL statement extraction failed.

[0082] Taking the first code segment among multiple code segments as an example, the server can parse the code statements in the first code segment to obtain the initial SQL statement; detect whether there is a target variable whose variable value needs to be completed in the initial SQL statement; obtain the variable value of the target variable based on the detection that there is a target variable whose variable value needs to be completed in the initial SQL statement; and determine that the first code segment is a code segment that failed to extract the SQL statement based on the fact that the variable value of the target variable was not obtained.

[0083] As described above, the code segment to be processed can be represented by a node in the AST (Abstract Syntax Tree), and the code statements in the code segment and the relationships between them can be represented by the child nodes of that node and the edges between nodes. Based on this, in this embodiment, the server can use the AST to parse the code statements in the first code segment to obtain the SQL statements.

[0084] For example, for the first code segment, the server can start from the second node representing the first code segment in the AST, and access each descendant node of the second node layer by layer according to the hierarchical relationship or dependency relationship between nodes. By parsing the relationship between each descendant node and the literals, variables, expressions, assignment statements, functions, etc. represented by each descendant node, the initial SQL statement can be obtained. Among them, the descendant nodes of the second node include the child nodes of the second node, the child nodes of the child nodes of the second node, etc.

[0085] Specifically, the server can determine at least one associated node of the target node by accessing the descendant nodes of the second node, and sequentially obtain the literals, variables, expressions, assignment statements, functions, etc., represented by the at least one associated node. The obtained content represented by the associated nodes is then concatenated to obtain the initial SQL statement. It should be noted that if the server fails to successfully obtain the content represented by a certain associated node, the server can determine that the SQL statement concatenation has failed; that is, this first code segment is the code segment where SQL statement extraction failed.

[0086] After obtaining the initial SQL statement, the server can further check whether the initial SQL statement contains variable placeholders. If the initial SQL statement contains variable placeholders, then the variable corresponding to the variable placeholder is the target variable whose value needs to be filled in; that is, the initial SQL statement contains a target variable whose value needs to be filled in. If the initial SQL statement does not contain variable placeholders, then the initial SQL statement does not contain a target variable whose value needs to be filled in.

[0087] If the initial SQL statement does not contain a target variable whose value needs to be completed, the server can treat this initial SQL statement as a successfully extracted SQL statement from the first code segment. Alternatively, the server can perform SQL syntax validation on the initial SQL statement. If the validation passes, the initial SQL statement is treated as a successfully extracted SQL statement from the first code segment. If the validation fails, the first code segment is determined to be the code segment where SQL statement extraction failed.

[0088] If the initial SQL statement contains a target variable whose value needs to be completed, the server can use DDL (Data Definition Language) to obtain the value of the target variable and then use the obtained value to complete the initial SQL statement. The DDL file can be uploaded by the user through a user-side device or obtained by the server from a specified device.

[0089] In some embodiments, the server can use the DDL file corresponding to the source code of the application to obtain the type of the target variable, and generate the variable value of the target variable based on the obtained type of the target variable.

[0090] It should be noted that the DDL file contains data table information, which includes information about each column in the table, such as the column name and data type. Based on this, the server can look up the data type of the target column corresponding to the target variable from this data table information.

[0091] For example, the server can parse the fields preceding the variable name of the target variable to obtain the column name of the target column corresponding to the target variable. Then, the server can search for column information containing the column name of the target column from the data table information included in the DDL file; this column information is the target column information. If the target column information is found, the server retrieves the data type of the target column from this information; the data type of the target column is the type of the target variable. Based on this, the server generates the variable value of the target variable based on the data type of the target column and uses the generated variable value to complete the initial SQL statement. The completed SQL statement is the SQL statement successfully extracted from the first code segment.

[0092] For example, if the target column's data type is string, the server can generate a random string value as the target variable's value. As another example, if the target column's data type is date, the server can generate a date as the target variable's value.

[0093] Optionally, if the information of the target column corresponding to the target variable is not found, the server will not be able to obtain the data type of the target column, that is, it will not be able to obtain the type of the target variable. In this case, the server can determine that the first code segment is the code segment that failed to extract the SQL statement.

[0094] Optionally, in some cases, before retrieving the value of the target variable from the DDL file, the server can first search for the variable name of the target variable in the source code and find the corresponding data type. If a data type is found, a variable value of that data type is generated and used as the value of the target variable to complete the initial SQL statement. If no data type is found, the server can then retrieve the value of the target variable from the DDL file.

[0095] Optionally, after completing the initial SQL statement using the obtained target variable value, the server can also perform SQL syntax validation on the completed SQL statement. If the validation passes, the completed SQL statement is determined to be the successfully extracted SQL statement from the first code segment. If the validation fails, the first code segment is determined to be the code segment where SQL statement extraction failed.

[0096] The following example, using the code segment in Table 1 below, illustrates the process of statically extracting SQL statements from a code segment. As shown in Table 1, the `findReportId` method contains SQL statements. When traversing the AST, the server, upon reaching the first node corresponding to the second line of code in the code segment, finds that the literal represented by this first node contains the SQL keyword "select". Through this first node, the server can locate the second node that indicates the `findReportId` method containing the SQL keyword. Then, starting from the second node, the server can sequentially access its child nodes to parse the concatenation operation of the SQL statement within the `findReportId` method. Specifically, when the server accesses the child node corresponding to the second line of code, it stores "select*from users where report_id in:reportId" as the value of the SQL variable. When accessing the child node corresponding to the statement in line 3, the stored "select * from users where report_id in:reportId" and the newly added string "and check = ${check}" are concatenated, and the value of the SQL variable is updated using the concatenated string. Afterwards, other nodes are accessed. Since the variables and expressions represented by other child nodes do not contain concatenation operations on the SQL variable, the updated value of the SQL variable is the final concatenated SQL statement, i.e., the initial SQL statement. This initial SQL statement is "select * from users where report_id in:reportId and check = ${check}".

[0097] After extracting the initial SQL statement from the following code snippet, the server can determine the target variables, such as `reportId` and `check`, whose variable values ​​are variable placeholders. Based on this, the server checks the variables in the SQL statement using lines 5 to 7 of the code snippet. By passing a map to `this.getList` and parsing the parameter types in the map to determine the type of the corresponding variable, the server ultimately determines that `reportId` is of type `List`. <integer>The type of `check` is boolean. Based on this, the server can use the data types determined above to generate data of the corresponding data types to complete the variable values ​​of `reportId` and `check`. For example, if the generated variable value of `reportId` is "(1)" and the variable value of `check` is "true", then the final completed SQL statement is: `select * from users where report_id in (1) and check = true`.

[0098] Table 1 First Code Segment

[0099]

[0100] For each of the multiple code segments, the server can perform static analysis to extract the SQL statements from each segment using the methods described above. For successfully extracted code segments, the extracted SQL statements are the SQL statements obtained from the corresponding code segment. For code segments where extraction fails, the server can use these code segments to generate corresponding test cases, allowing the SQL statements to be dynamically obtained by executing the test cases.

[0101] Taking the code segment where SQL statement extraction failed, including the second code segment, as an example, the server can determine the execution location of the SQL statement in the second code segment, determine the initial call function corresponding to the SQL statement based on the execution location of the SQL statement, and generate test cases corresponding to the second code segment based on the initial call function.

[0102] For example, the server can determine the target function containing the SQL statement based on the function containing the target literal containing the SQL keyword in the second code segment, and then determine the initial calling function corresponding to the target function through the function call chain of the target function.

[0103] For example, if the target function containing the target literal is the first function, the server can determine whether there is a second function that calls the first function. After determining the second function, it can then determine whether there is a third function that calls the second function, and so on, until a function is traced back to a point where no other function calls it. This function is the initial calling function corresponding to the target function. This initial calling function can be the entry point function.

[0104] After determining the initial calling function, the server can generate corresponding parameter values ​​based on the parameters contained in the initial calling function, and use the parameter values ​​to construct test cases containing the initial calling function, thereby obtaining the test cases corresponding to the second code segment.

[0105] Table 2 Second Code Segment

[0106]

[0107] Table 3 Test cases corresponding to the second code segment

[0108]

[0109] For example, referring to the second code segment shown in Table 2 above, based on the location of the SQL keyword, the target function of the SQL statement is determined to be the `buildSQL` function. The `buildSQL` function is called by the `executeQuery` function, which in turn is called by the `getItems` function. That is, the function call chain is `getItems → executeQuery → buildSQL`. Therefore, the initial calling function corresponding to the target function is the `getItems` function. The `getItems` function contains two parameters: a String type `name` and an int type `count`. Based on this, the server can generate the parameter values ​​for these two parameters according to their types. For example, the parameter value for `name` can be "aaa", and the parameter value for `count` can be "10". A test case can be constructed using the `getItems` function and these two parameter values, and then the `getItems` function can be called through this test case. For example, the code for the test case is shown in Table 3 above.

[0110] For each code segment where SQL statement extraction fails, the server can refer to the above method to generate test cases for the corresponding code segment.

[0111] In another possible implementation, after the server locates multiple code segments containing SQL keywords via S401, it may not perform static analysis on each code segment to extract SQL statements. Instead, it can directly generate corresponding test cases based on each code segment. The implementation method for generating corresponding test cases based on each code segment can refer to the implementation process for generating test cases based on the second code segment described above, and will not be repeated here.

[0112] S403: Execute the test cases and retrieve the SQL statements generated during the execution of the test cases.

[0113] After generating at least one test case corresponding to at least one code segment, the server can execute the at least one test case and obtain the SQL statements generated during the execution of each test case.

[0114] For example, the server can identify the SQL execution function for executing the SQL statement within the function call chain of the target function. Using instrumentation, a code segment for retrieving the SQL statement is inserted into this SQL execution function. Based on this, when executing test cases, the server calls the SQL execution function through the initial call function in the test case to generate the SQL statement to be executed and then executes it. At this point, the instrumented code segment can be used to retrieve the SQL statement to be executed.

[0115] For example, still using the code snippet shown in Table 2 and the test case shown in Table 3, the server can instrument the pstmt.executeQuery function used to execute the SQL statement. When this test case is executed, the getItems function calls the executeQuery function, which in turn calls the pstmt.executeQuery function to execute the SQL statement. At this point, the SQL statement executed by the pstmt.executeQuery function can be obtained through the instrumented code snippet. The obtained SQL statement is: SELECT * FROM items WHERE name = "aaa" and count = 10 and createTime >= "2025-01-01 00:00:00".

[0116] After obtaining the SQL statements from the source code using the methods described above, the server can send the source code and the location of each SQL statement within it to the user-side device. Upon receiving the location of each SQL statement and the source code, the user-side device can mark the SQL statements in the source code based on their positions and then display the marked source code.

[0117] For example, the location of an SQL statement in the source code can include the location of each statement segment of the SQL statement in the source code. In this way, the user-side device can mark the statement segments contained in the corresponding SQL statement in the source code by adding highlights, underlines, bolding, or other marking methods based on the location of the SQL statement, and then display the marked source code.

[0118] In summary, this embodiment of the application uses static analysis of the application's source code to locate code segments containing SQL keywords. Based on this, test cases are generated using the identified code segments and executed to obtain the SQL statements generated during test case execution. Therefore, this embodiment combines static and dynamic analysis to extract SQL statements from the application's source code. Static analysis of the source code allows for the comprehensive identification of code segments containing SQL statements. Dynamic analysis, using test cases corresponding to these code segments, yields complete and accurate SQL statements.

[0119] Furthermore, in this embodiment, for multiple code segments containing SQL keywords, static analysis can be performed on each code segment to extract the SQL statements. Based on this, for successfully extracted code segments, it is unnecessary to generate test cases to obtain the SQL statements; for code segments where extraction fails, test cases are generated to obtain the SQL statements. This reduces server resource consumption.

[0120] Finally, in the embodiments of this application, when extracting SQL statements by performing static analysis on code segments, if there are target variables in the SQL statements whose variable values ​​need to be completed, the DDL file can be used to complete the variable values ​​of the target variables, thereby obtaining a complete SQL statement.

[0121] It is worth noting that in the above embodiment, after locating multiple code segments containing SQL keywords from the source code, static analysis can be performed on these multiple code segments to extract SQL statements. For code segments where SQL statement extraction fails, corresponding test cases are generated to obtain the SQL statements. Based on this, if SQL statements are successfully extracted from each of the multiple code segments through static analysis, the server does not need to execute S402 and S403.

[0122] The method for obtaining SQL statements described in the above embodiments, Figure 5 An exemplary flowchart for retrieving SQL statements is provided.

[0123] like Figure 5 As shown, this exemplary process mainly includes three stages: locating the code segment to be processed, statically extracting the SQL statements from the code segment, and dynamically analyzing the code segments that failed to be extracted statically.

[0124] When locating the code segment to be processed, the server first reads the application's source code file and parses it to obtain an Abstract Syntax Tree (AST). It then searches for the first node representing a literal in the AST and determines whether the literal represented by that node contains the SQL keyword. If so, the method containing the SQL keyword literal is identified as the code segment to be processed.

[0125] After identifying the code segment to be processed, the server can then perform static analysis to extract the code segment.

[0126] The server first parses the code statements in the code segment to extract and concatenate SQL statement fragments. If concatenation is successful, it checks if the target variable to be completed exists in the concatenated SQL statement. If no target variable exists, the concatenated SQL statement is output. If a target variable exists, it is completed based on the DDL file, and the completion is checked for success. If completion is successful, the completed SQL statement is output. If either concatenation or completion fails, the server can perform dynamic analysis on the code segment.

[0127] When performing dynamic analysis on a code segment, the server first obtains the function call chain corresponding to the target function containing the SQL keyword in the code segment. Test cases are then generated based on the initial calling functions in the function call chain. The test cases are executed, and the SQL statements generated during the execution of those test cases are retrieved.

[0128] After obtaining the SQL statements from the source code using the methods described above, the server can execute other tasks based on the obtained SQL statements. For example, when the method for obtaining SQL statements described above is applied to a database migration scenario, the source code of the application mentioned in S401 can be the source code running on the source database, such as the first database. Thus, after obtaining the SQL statements from this source code through S401 to S403, the server can also... Figure 4 S404 and S405 shown modify the application's source code to obtain source code that is compatible with the target database, such as the second database, thereby enabling the application to be migrated to the second database for operation.

[0129] S404: Convert the SQL statements in the obtained SQL statements that are not compatible with the second database, and obtain SQL statements that are compatible with the first database.

[0130] In this embodiment, the obtained SQL statement refers to the SQL statement included in the source code of the aforementioned application. The application's source code is adapted to the first database; that is, the SQL statements in the source code are adapted to the SQL syntax of the first database, enabling the application to run on the first database. Therefore, the obtained SQL statement is an SQL statement adapted to the first database. Specifically, the obtained SQL statement may include the SQL statement obtained during the execution of the test cases corresponding to the code segment, as described above. Optionally, it may also include SQL statements successfully extracted from the code segment to be processed through static analysis.

[0131] When an application needs to migrate from a first database to a second database that is different from the first database, the SQL syntax of the second database and the first database may be different. Therefore, the SQL statements in the application's source code may not be compatible with the SQL syntax of the second database, causing the application to fail to run on the second database. Based on this, in this embodiment, the server can first detect whether each obtained SQL statement is compatible with the second database. If any SQL statement is incompatible with the second database, then the SQL statement is converted.

[0132] Taking the first SQL statement in the obtained source code as an example, the server can determine whether the syntax of the first SQL statement matches the SQL syntax of the second database based on the syntax rules of the second database. If the syntax of the first SQL statement does not match the SQL syntax of the second database, the server will convert the first SQL statement.

[0133] In one example, the server can use an SQL transformation rule base to transform a first SQL statement to obtain a second SQL statement adapted to a second database. The SQL transformation rule base can include multiple pre-collected transformation rules, each rule used to transform a type of SQL statement adapted to the first database into an SQL statement adapted to the second database.

[0134] For example, each transformation rule in the SQL transformation rule base can include a source SQL statement and a corresponding target SQL statement. The source SQL statement and the corresponding target SQL statement are used to perform the same database operation, with the source SQL statement adapted to a first database and the target SQL statement adapted to a second database. Based on this, the server can search the SQL transformation rule base for a first transformation rule that matches the first SQL statement, and then transform the first SQL statement based on the target SQL statement contained in the first transformation rule to obtain a second SQL statement adapted to the second database.

[0135] In another example, the server can also use an SQL transformation model to transform the first SQL statement to obtain a second SQL statement that is adapted to the second database.

[0136] The SQL transformation model can be pre-trained using a large number of source SQL statement samples adapted to the first database and corresponding target SQL statement samples adapted to the second database. Based on this, the server can input the first SQL statement into the SQL transformation model, which will transform the first SQL statement to output the second SQL statement.

[0137] For each SQL statement that is incompatible with the second database, the server can refer to the method described above for converting the first SQL statement to convert the corresponding SQL statement, thereby obtaining multiple SQL statements that are compatible with the second database.

[0138] As described above, the server can display source code marked with SQL statements on the user-side device. Furthermore, the server can send individual SQL statements in the source code that are incompatible with the second database, along with their corresponding converted SQL statements, to the user-side device. This allows the user-side device to display not only the marked source code but also the converted SQL statements corresponding to the marked SQL statements in the source code.

[0139] For example, for a first SQL statement that is incompatible with the second database, the user-side device can directly display the converted second SQL statement near the third code segment containing the first SQL statement, allowing the user to compare and view it. Alternatively, the user can click on any statement fragment in the first SQL statement marked in the source code, and the user-side device will display the second SQL statement in response to the user's click.

[0140] Optionally, in some possible cases, after the user-side device displays the converted SQL statement, the user can also modify the converted SQL statement. For example, taking the second SQL statement obtained by converting the first SQL statement as an example, the user can modify the second SQL statement on the user-side device. Based on this, the user-side device can also send the first SQL statement and the user-modified second SQL statement to the server. The server can then update the SQL conversion rule base or SQL conversion model used to convert the first SQL statement based on the first SQL statement and the modified second SQL statement.

[0141] For example, when converting SQL statements using an SQL conversion rule base, the server can generate a first conversion rule based on the first SQL statement and the modified second SQL statement. Then, the second conversion rule in the SQL conversion rule base, which was originally used to convert the first SQL statement into the second SQL statement, is replaced with the first conversion rule.

[0142] S405: Modify the application's source code based on the converted SQL statements.

[0143] After converting the obtained SQL statements that are incompatible with the second database, the server can also automatically modify the application's source code based on each converted SQL statement, and the modified source code will be compatible with the second database.

[0144] For example, taking the second SQL statement obtained by converting the first SQL statement in the source code as an example, the server can modify the third code segment in the source code that contains the first SQL statement based on the second SQL statement, and the modified third code segment contains the second SQL statement.

[0145] Specifically, the server can identify a third code segment containing the first SQL statement within the source code. Based on this, the server can replace the relevant content of the first SQL statement in the third code segment with the relevant content of the second SQL statement, thus obtaining a modified third code segment. For example, multiple statement fragments from the first SQL statement may be scattered throughout the third code segment; the server can replace each statement fragment with its corresponding statement fragment from the second SQL statement, thereby obtaining the modified third code segment.

[0146] It's important to note that some current implementations that use dynamic analysis to capture SQL statements in applications directly use instrumentation techniques to insert code segments and capture the SQL statements executed during application runtime. Since the source code isn't analyzed, the location of the captured SQL statement within the source code cannot be determined. Therefore, even if the SQL statement is transformed, its location in the source code remains unidentified, making it impossible to automatically modify the corresponding SQL statement in the source code using the transformed SQL.

[0147] In this embodiment, as described above, the method relies on source code to locate the code segment containing the SQL statement to be processed, and then obtains the SQL statement through static or dynamic analysis of the code segment. Based on this, for any SQL statement in the obtained source code, the server can determine the code segment containing the corresponding SQL statement within the source code. That is, it can determine the location of the SQL statement in the source code. Furthermore, after converting the SQL statement, the server can automatically modify the SQL statement in the source code based on its location in the source code, achieving automatic adaptation and modification of the source code, and improving database migration efficiency.

[0148] After modifying the source code based on the converted SQL statements, the server can also send the modified source code to the user's device for display.

[0149] Figure 6 This is a schematic diagram illustrating how, in a database migration scenario, the source code of an application adapted to a first database is converted to adapt to a second database. For example... Figure 6 As shown, for SQL statements successfully extracted through static analysis and those extracted through dynamic analysis, these SQL statements are transformed using a pre-defined SQL transformation rule base, and the source code is automatically modified using the transformed SQL statements. The modified source code is then output. Furthermore, user modifications to the transformed SQL statements in the modified source code can be obtained, and new transformation rules can be generated using these user-modified SQL statements. These new transformation rules are then used to update the SQL transformation rule base.

[0150] In this embodiment, when the application's source code is adapted to the first database, if the application needs to be migrated to the second database for operation, the server can convert the SQL statements in the obtained source code. Since this embodiment relies on the source code to locate the code segment containing the SQL statements to be processed, and then obtains the SQL statements through static or dynamic analysis of the code segment, the location of any SQL statement in the obtained source code can be automatically located. Therefore, the source code can be automatically modified based on the converted SQL statements, achieving automatic adaptation and modification of the source code. This reduces the difficulty of migrating the application's source code during database migration, reduces the migration workload, and improves database migration efficiency.

[0151] In addition, in this embodiment, the converted SQL statement can be modified by the user. Based on this, the SQL conversion rule base or SQL conversion model is continuously updated based on the user-modified SQL statement and the corresponding original SQL statement in the source code. This helps to improve the accuracy of subsequent SQL statement conversions.

[0152] The apparatus for obtaining SQL statements provided in the embodiments of this application will be described next.

[0153] Figure 7 This is a schematic diagram of the structure of a device for obtaining SQL statements provided in an embodiment of this application. Figure 7 As shown, the device 70 for obtaining SQL statements includes a static analysis module 71 and a dynamic analysis module 72.

[0154] The static analysis module 71 is used to execute S401 in the aforementioned embodiments, and the dynamic analysis module 72 is used to execute S402 and S403 in the aforementioned embodiments.

[0155] It should be noted that the device 70 for obtaining SQL statements can be deployed in computer devices such as server-side devices and user-side devices as described above. For example, the device 70 can be deployed in a server or terminal device. Alternatively, different functional modules in the device 70 can be deployed in different servers in a service cluster.

[0156] For example, see Figure 8 The static analysis module 71 includes an SQL location unit 711, which is used to perform static analysis on the source code of the application to obtain multiple code segments to be processed.

[0157] Optionally, see Figure 8 The static analysis module 71 may further include a static extraction unit 712, which is used to extract SQL statements from each of the multiple code segments. Correspondingly, the dynamic analysis module 72 is used to generate corresponding test cases based on at least one code segment where the extraction of SQL statements fails.

[0158] Optionally, the static extraction unit 712 is specifically used to parse the code statements in the first code segment among multiple code segments to obtain an initial SQL statement; detect whether there is a target variable whose variable value needs to be completed in the initial SQL statement; based on the detection that there is a target variable whose variable value needs to be completed in the initial SQL statement, use the DDL file corresponding to the source code to obtain the variable value of the target variable; based on the fact that the variable value of the target variable is not obtained, determine that the first code segment is a code segment in which the extraction of the SQL statement failed, or, based on the obtained variable value of the target variable, use the variable value of the target variable to complete the initial SQL statement, and determine the completed SQL statement as the SQL statement successfully extracted from the first code segment.

[0159] Optionally, the static extraction unit 712 is specifically used to: obtain data table information from a first database based on a DDL file, wherein the first database is the database used when the source code is run; search for the data type of the target column corresponding to the target variable in the data table information; generate the variable value of the target variable based on the data type of the target column found, or determine the variable value of the target variable that was not obtained based on the data type of the target column not found.

[0160] Optionally, at least one code segment includes a second code segment, and the dynamic analysis module 72 is specifically used to determine the initial calling function on the function call chain where the target function containing the SQL statement in the second code segment is located; and to generate test cases corresponding to the second code segment based on the initial calling function.

[0161] Optionally, see Figure 8 The device 70 may further include a statement conversion module 73, used to detect whether a first SQL statement in the source code that is compatible with the first database is compatible with the second database. The second database is different from the first database. The first SQL statement is an SQL statement obtained during the execution of test cases or an SQL statement successfully extracted from a code segment other than at least one code segment. If the first SQL statement is not compatible with the second database, the first SQL statement is converted to obtain a second SQL statement, which is an SQL statement compatible with the second database.

[0162] Optionally, the device 70 further includes a code modification module 74, which is used to modify a third code segment in the source code containing the first SQL statement based on the second SQL statement, wherein the modified third code segment contains the second SQL statement.

[0163] Optionally, see Figure 8 The second SQL statement is obtained by converting the first SQL statement based on the SQL conversion rule base. In this case, the device 70 further includes a user interface module 75 and a rule base update module 76. The user interface module 75 is used to display the first SQL statement and the second SQL statement, and to obtain the modified second SQL statement in response to the user's modification operation on the second SQL statement. The rule base update module 76 is used to update the SQL conversion rule base based on the first SQL statement and the modified second SQL statement.

[0164] Optionally, the user interface module 75 is also used to display source code marked with SQL statements.

[0165] In this embodiment, static analysis of the application's source code is used to locate code segments containing SQL keywords. Based on this, test cases are generated using the identified code segments and executed to obtain the SQL statements generated during test case execution. Therefore, this embodiment combines static and dynamic analysis to extract SQL statements from the application's source code. Static analysis of the source code allows for the comprehensive identification of code segments containing SQL statements. Dynamic analysis, using test cases corresponding to these code segments, yields complete and accurate SQL statements.

[0166] It should be noted that the module division in the device for obtaining SQL statements provided in the above embodiments is illustrative and only represents one logical functional division. In actual implementation, other division methods are also possible. Furthermore, the functional modules in the various embodiments of this application can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0167] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a server, terminal, or other device) or processor to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0168] Furthermore, the apparatus for obtaining SQL statements and the method for obtaining SQL statements provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.

[0169] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital versatile discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0170] In the various embodiments of this application, unless otherwise specified or logically conflicting, the terminology and / or descriptions between different embodiments are consistent and can be referenced mutually. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships. In the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the association relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone, where A and B can be singular or plural. In the textual description of the embodiments of this application, the character " / " generally indicates that the preceding and following related objects have an "or" relationship. In this application, "first," "second," and various numerical designations are only for ease of description and are not used to limit the scope of the embodiments of this application. For example, they are used to distinguish different messages, rather than to describe a specific order or sequence.

[0171] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers does not imply the order of execution; the execution order of each process should be determined by its function and internal logic.

[0172] Finally, it should be noted that the above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.< / integer>

Claims

1. A method for obtaining Structured Query Language (SQL) statements, characterized in that, The method includes: Static analysis is performed on the application's source code to obtain multiple code segments to be processed, each of which contains SQL keywords; Test cases are generated based on at least one of the multiple code segments; Execute the test cases and obtain the SQL statements generated during the execution of the test cases.

2. The method according to claim 1, characterized in that, The method further includes: extracting SQL statements from each of the plurality of code segments; The step of generating test cases based on at least one of the plurality of code segments includes: Generate corresponding test cases based on at least one code segment that failed to extract the SQL statement.

3. The method according to claim 2, characterized in that, Extracting SQL statements from each of the plurality of code segments includes: The code statements in the first code segment of the plurality of code segments are parsed to obtain the initial SQL statement; Detect whether there is a target variable whose value needs to be filled in the initial SQL statement; Based on the detection that there is a target variable in the initial SQL statement that needs to be completed, the variable value of the target variable is obtained using the data definition language (DDL) file corresponding to the source code; Based on the fact that the value of the target variable was not obtained, the first code segment is determined to be a code segment in which the extraction of the SQL statement failed. Alternatively, based on the fact that the value of the target variable was obtained, the initial SQL statement is completed using the value of the target variable, and the completed SQL statement is determined to be the SQL statement successfully extracted from the first code segment.

4. The method according to claim 3, characterized in that, The step of obtaining the variable value of the target variable using the Data Definition Language (DDL) file corresponding to the source code includes: Based on the DDL file, obtain the data table information in the first database, where the first database is the database used by the source code during runtime; Find the data type of the target column corresponding to the target variable in the data table information; Based on the data type of the target column being found, the variable value of the target variable is generated using the data type of the target column; or, based on the data type of the target column not being found, it is determined that the variable value of the target variable has not been obtained.

5. The method according to any one of claims 1 to 4, characterized in that, The at least one code segment includes a second code segment, and the generation of test cases based on at least one of the plurality of code segments includes: Determine the initial calling function in the function call chain of the target function containing the SQL statement in the second code segment; Test cases corresponding to the second code segment are generated based on the initial function call.

6. The method according to any one of claims 1 to 5, characterized in that, The source code is source code adapted to the first database, and the method further includes: The test checks whether the first SQL statement is compatible with the second database, which is different from the first database. The first SQL statement is an SQL statement obtained during the execution of the test case or an SQL statement successfully extracted from other code segments besides the at least one code segment. If the first SQL statement is not compatible with the second database, the first SQL statement is converted to obtain a second SQL statement, which is an SQL statement compatible with the second database.

7. The method according to claim 6, characterized in that, The method further includes: Based on the second SQL statement, the third code segment containing the first SQL statement in the source code is modified, and the modified third code segment contains the second SQL statement.

8. The method according to claim 6 or 7, characterized in that, The second SQL statement is obtained by transforming the first SQL statement based on an SQL transformation rule base. The method further includes: Display the first SQL statement and the second SQL statement; In response to the user's modification operation on the second SQL statement, obtain the modified second SQL statement; The SQL transformation rule base is updated based on the first SQL statement and the modified second SQL statement.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: The source code marked with SQL statements is displayed.

10. An apparatus for obtaining SQL statements, characterized in that, The apparatus includes at least one module for performing the method for obtaining SQL statements as described in any one of claims 1 to 9.

11. A computer device, characterized in that, The computer device includes a processor for executing a computer program stored in a memory to implement the method for obtaining SQL statements as described in any one of claims 1 to 9.

12. A computer program product containing instructions, characterized in that, When the instruction is executed by a computer device, the computer device performs the method for obtaining SQL statements as described in any one of claims 1 to 9.

Images