Version updating method and device, equipment and storage medium

Abstract

The application discloses a version updating method and device, equipment and a storage medium, relates to the technical field of version updating, and the version updating method comprises the following steps: obtaining version information to be updated of software to be updated, intercepting an original structured query language (SQL), and generating a syntax tree corresponding to the original SQL, wherein the version information to be updated comprises SQL to be updated and a code block to be updated; according to the SQL to be updated, converting the syntax tree to generate target SQL after field updating; according to a code task identifier of the code block to be updated, determining a code position of an original code block, and generating target code; and based on the target SQL and the target code, performing version updating and testing on the software to be updated to complete a version updating task. The application can help a low-code platform to accurately identify a data and code change range, realize automatic merging of code and scripts, and achieve the purpose of reducing time consumption of version updating.

Description

Technical Field

[0001] This application relates to the field of version update technology, and in particular to a version update method, apparatus, device and storage medium. Background Technology

[0002] Low-code platforms significantly shorten delivery cycles through visual modeling and automated code generation, making version releases a critical path for continuous iteration. Current industry practice employs two strategies to identify incremental data: "full backup + difference comparison" or "change tagging." The former involves taking a snapshot of the entire database before each release and comparing it line-by-line with the previous version, while the latter requires manual input of tag fields for each addition, deletion, or modification. Therefore, full comparisons expand linearly with the data volume, extending the release window to hours, becoming a key bottleneck in the continuous delivery process of low-code platforms. Summary of the Invention

[0003] The main purpose of this application is to provide a version update method, apparatus, device and storage medium, which aims to help low-code platforms accurately identify the scope of data and code changes and realize the automatic merging of code and scripts, thereby reducing the time spent on version updates.

[0004] To achieve the above objectives, this application proposes a version update method, the method comprising:

[0005] Obtain the update version information of the software to be updated, intercept the original structured query language SQL, and generate the syntax tree corresponding to the original SQL. The update version information includes the SQL to be updated and the code block to be updated.

[0006] Based on the SQL to be updated, the syntax tree is updated with fields and then transformed to generate the target SQL;

[0007] Based on the code task identifier of the code block to be updated, determine the code location of the original code block and generate the target code;

[0008] Based on the target SQL and the target code, the software to be updated is updated and tested to complete the version update task.

[0009] In one possible implementation, the interception of the original Structured Query Language (SQL) and the generation of a syntax tree corresponding to the original SQL includes:

[0010] Deploy an SQL interceptor adapted to the data interaction framework of the software to be updated, and capture the original SQL during the execution of the software to be updated through the SQL interceptor;

[0011] The original SQL is parsed using a syntax analysis tool to identify its statement type.

[0012] Based on the statement type of the original SQL, a syntax tree is constructed that is consistent with the syntax structure of the original SQL. The syntax tree contains a list of fields, a list of values, and logical relationship nodes of the original SQL.

[0013] In one possible implementation, obtaining the update version information of the software to be updated includes:

[0014] Receive a version update request instruction for the software to be updated, wherein the version update request instruction includes the version update target, the scope of functional changes and data adjustment requirements;

[0015] Based on the version update target, the basic version information of the software to be updated is retrieved from the version management repository. The basic version information includes the basic code library and the basic database table structure.

[0016] Based on the scope of the functional changes, the code blocks to be updated are selected, and the SQL to be updated is generated according to the data adjustment requirements;

[0017] The code block to be updated and the SQL to be updated are combined to form the version information to be updated.

[0018] In one possible implementation, the step of updating the syntax tree and transforming it to generate the target SQL based on the SQL to be updated includes:

[0019] Parse the SQL to be updated and extract the target fields contained in the SQL to be updated. The target fields include the change version number field, the operation type field, and the release status field.

[0020] Based on the statement type corresponding to the original SQL, locate the relevant nodes in the syntax tree related to the target field, insert the target field into the relevant nodes in the syntax tree, and simultaneously supplement the value information corresponding to the target field;

[0021] Perform syntax validation on the updated syntax tree. Once the validation passes, convert the syntax tree back into executable target SQL.

[0022] In one possible implementation, determining the code location of the original code block and generating the target code based on the code task identifier of the code block to be updated includes:

[0023] Establish a code task association table for the software to be updated. The code task association table records the storage path, module affiliation, and dependency relationship between the code task identifier and the original code block.

[0024] The code task identifier of the code block to be updated is matched with the code task association table to determine the code location of the original code block;

[0025] Extract the code logic framework of the original code block, and embed the functional code fragments in the code block to be updated into the code logic framework to form the preliminary target code;

[0026] Dependency checks and syntax corrections are performed on the preliminary target code, and it is determined whether the preliminary target code is compatible with the existing code structure of the software to be updated, thereby generating the target code.

[0027] In one possible implementation, the step of performing version updates and testing on the software to be updated based on the target SQL and the target code to complete the version update task includes:

[0028] The target code is deployed to the code module corresponding to the software to be updated, replacing the original code block to form a software version with updated code;

[0029] The target SQL is executed in the test database of the software to be updated to complete the database table structure adjustment and data update, forming the updated database version.

[0030] The software version after code updates and the database version after data updates are subjected to joint debugging tests, which include functional testing, performance testing and compatibility testing.

[0031] If the test fails, adjust the target code and target SQL according to the test error message, and re-execute the integration test until the test passes;

[0032] If the test passes, the target code and the target SQL will be synchronously deployed to the production environment of the software to be updated, thus completing the version update task.

[0033] In one possible implementation, the joint debugging test between the updated software version and the updated database version includes:

[0034] Construct a test environment consistent with the production environment of the software to be updated, the test environment including servers, databases and dependent components with the same configuration;

[0035] For the scope of functional changes to the software to be updated, a test case set is designed, which includes normal scenario test cases, abnormal scenario test cases, and boundary scenario test cases.

[0036] Run the test case set to monitor the function execution results, response time, and resource consumption of the software version after the code update, and verify the integrity, consistency, and accuracy of the data in the database version after the data update;

[0037] Record test error information during the testing process and generate a test report based on the test error information. The test report is used to determine whether the joint debugging test is passed. The test error information includes the error location, error type and error triggering conditions.

[0038] Furthermore, to achieve the above objectives, this application also proposes a version update apparatus, which includes:

[0039] The acquisition module is used to acquire the update version information of the software to be updated, intercept the original structured query language SQL, and generate the syntax tree corresponding to the original SQL. The update version information includes the SQL to be updated and the code block to be updated.

[0040] The generation module is used to update the fields of the syntax tree based on the SQL to be updated and then transform it to generate the target SQL.

[0041] The determination module is used to determine the code location of the original code block based on the code task identifier of the code block to be updated, and to generate the target code;

[0042] The update module is used to perform version updates and tests on the software to be updated based on the target SQL and the target code, and complete the version update task.

[0043] In addition, to achieve the above objectives, this application also proposes a version update device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the version update method as described above.

[0044] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the version update method described above.

[0045] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the version update method described above.

[0046] This application provides a version update method, apparatus, device, and storage medium. The version update method obtains the version information of the software to be updated, intercepts the original Structured Query Language (SQL), and generates a syntax tree corresponding to the original SQL. The version information includes the SQL to be updated and the code block to be updated. Based on the SQL to be updated, the syntax tree is updated with fields and transformed to generate target SQL. The code location of the original code block is determined based on the code task identifier of the code block to be updated, and target code is generated. Based on the target SQL and the target code, the software to be updated is updated and tested to complete the version update task. This avoids oversights in manually writing SQL, reduces data operation errors, and determines the location of the original code block based on the code task identifier, updating only related code to avoid invalid code changes, reducing interference with the existing code system of the software, and improving code update efficiency. It supports processing SQL by table dimension and processing code by task dimension, which is suitable for incremental update scenarios of low-code platforms, can quickly respond to version change requirements, and reduce the time and resource consumption of full updates. Attached Figure Description

[0047] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0048] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0049] Figure 1 This is a flowchart illustrating an embodiment of the method for updating the version of this application.

[0050] Figure 2 Example diagram of a syntax tree scenario implementation provided for the update method of this application;

[0051] Figure 3 This is a schematic diagram of the module structure of the version update device according to an embodiment of this application;

[0052] Figure 4 This is a schematic diagram of the device structure of the hardware operating environment involved in the version update method in this application embodiment.

[0053] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0054] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0055] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0056] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device, big data service platform, or version update system capable of implementing the above functions. The following description uses a version update system as an example to illustrate this embodiment and the subsequent embodiments.

[0057] Based on this, this application provides a version update method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the update method for this application.

[0058] In this embodiment, the version update method includes steps S11 to S14:

[0059] Step S11: Obtain the update version information of the software to be updated, intercept the original structured query language SQL, and generate the syntax tree corresponding to the original SQL. The update version information includes the SQL to be updated and the code block to be updated.

[0060] It should be noted that "software to be updated" refers to software systems that require feature iteration, data adjustments, or bug fixes, encompassing enterprise business management systems, applications developed on low-code platforms, etc. "Version information to be updated" refers to the core data set supporting this version update, explicitly including the SQL to be updated and the code blocks to be updated. The SQL to be updated defines data change requirements (such as adding fields or modifying data), while the code blocks to be updated define feature adjustment requirements (such as adding new feature logic or optimizing old features). The original Structured Query Language (SQL) refers to the unmodified SQL statements used by the updated software to interact with the database during operation. Common types include INSERT, UPDATE, and MERGE INTO statements, directly used for adding, modifying, or merging data. The syntax tree refers to the tree-like data structure formed after decomposing the original SQL, containing field list nodes, value list nodes, SET clause nodes, etc., providing precise operation locations for field updates.

[0061] For details, please refer to steps S21-S34, which will not be repeated here.

[0062] Step S12: Based on the SQL to be updated, the syntax tree is updated with fields and then transformed to generate the target SQL;

[0063] It should be noted that the SQL to be updated refers to the set of SQL statements that define the data adjustment requirements for this version update. It includes logic such as adding fields and modifying data, and carries additional version management field information (such as the changed version number, operation type, and release status). The target SQL refers to the executable SQL statement generated by reconstructing the syntax tree after the field updates. It retains the original SQL business logic, adds version management fields, and has complete syntax that can be directly executed in the database.

[0064] For details, please refer to steps S41-S43, which will not be repeated here.

[0065] Step S13: Determine the code location of the original code block based on the code task identifier of the code block to be updated, and generate the target code;

[0066] It should be noted that the code block to be updated refers to the code fragment that implements the software function change, including new functional logic, optimization of old functions, or defect fixes, and is associated with a unique code task identifier. The code task identifier is a unique identifier (string or number) assigned to the code block to be updated, which has a pre-defined association with the original code block and is used to accurately locate the original code block. The original code block refers to the existing code fragment in the software related to the function of the code block to be updated, containing a complete code logic framework (class definitions, method structures, dependency references), and is the embedding carrier of the code block to be updated. The code location refers to the storage path, module, and specific file location of the original code block in the software code repository, clarifying the embedding scope of the code block to be updated. The target code refers to the executable code formed after the code block to be updated is embedded into the original code block, undergoing dependency checks, syntax correction, and compatibility verification, and is compatible with the existing code system of the software to achieve the expected function.

[0067] For details, please refer to steps S51-S54, which will not be repeated here.

[0068] Step S14: Based on the target SQL and the target code, perform version update and testing on the software to be updated to complete the version update task.

[0069] It's important to clarify that version update refers to deploying the target code to the corresponding software module and executing the target SQL in the database, achieving synchronized iteration between code and data. Testing refers to the integration testing of the updated software version and the updated database version. The version update task encompasses the entire process from deploying the target code and target SQL to passing tests and going live in production. Completion is marked by the new software version running normally in the production environment.

[0070] For details, please refer to steps S61-S74, which will not be repeated here.

[0071] This embodiment avoids oversights in manually writing SQL, reduces data operation errors, and determines the location of the original code block based on the code task identifier. It only updates related code, avoids invalid code changes, reduces interference with the existing code system of the software, and improves code update efficiency. It also supports processing SQL by table dimension and processing code by task dimension, which is suitable for incremental update scenarios of low-code platforms. It can quickly respond to version change requirements and reduce the time and resource consumption of full updates.

[0072] In one feasible implementation, the interception of the original Structured Query Language (SQL) and the generation of the syntax tree corresponding to the original SQL includes:

[0073] Step S21: Deploy an SQL interceptor adapted to the data interaction framework of the software to be updated, and capture the original SQL during the execution of the software to be updated through the SQL interceptor;

[0074] It's important to note that the data interaction framework of the software to be updated refers to the underlying technology framework used by the software to interact with the database. Common types include Mybatis and Hibernate. Different frameworks have different SQL execution flows and interface specifications, requiring targeted adaptation of interceptors. An SQL interceptor is a tool component that can be embedded in the data interaction framework and capture the SQL statements executed by the framework in real time. Its core function is to intercept and record the original SQL before it is sent to the database, without affecting the normal execution logic of the SQL.

[0075] In one possible implementation, when adapting to the Mybatis framework, the SQL interceptor implements the org.apache.ibatis.plugin.Interceptor interface provided by Mybatis. It specifies the intercepted methods (such as the Executor.update method, corresponding to SQL add and modify operations) through the @Intercepts annotation, ensuring accurate interception of SQL executed by Mybatis. When deploying the interceptor, it is configured in the core configuration file of Mybatis (such as mybatis-config.xml) so that it takes effect when the Mybatis framework starts. When capturing the original SQL, the interceptor extracts the SQL statement and parameter information from the Invocation object before the SQL is executed, temporarily stores the original SQL in the form of logs or cache, and allows the SQL to be sent to the database without affecting the normal business process of the software.

[0076] It should also be noted that the adaptability of the SQL interceptor directly determines the completeness of the original SQL capture: if the software uses multiple data interaction frameworks (such as some modules using Mybatis and some using JdbcTemplate), then the corresponding SQL interceptor of the framework needs to be deployed to avoid interception blind spots.

[0077] Specifically, based on the data interaction framework (such as Mybatis or Hibernate) used by the software to be updated, an SQL interceptor adapted to the framework's interface specification is developed to ensure compatibility with the framework's SQL execution flow. The adapted SQL interceptor is then configured in the software's data interaction framework configuration file, setting its scope of operation (e.g., specifying the business modules to be intercepted and the types of SQL operations), so that the interceptor runs upon software startup. Furthermore, when the software to be updated runs and triggers data interaction operations (such as adding or modifying data), the SQL interceptor intercepts and extracts the original SQL statement before it is sent to the database. Simultaneously, it records auxiliary information such as the SQL's execution time and the business module it belongs to, temporarily storing the original SQL in a specified storage location (e.g., memory cache or temporary log file). Subsequently, the original SQL is allowed to continue being sent to the database, ensuring the normal progress of the software's business processes.

[0078] Step S22: Call the syntax parsing tool to perform syntax decomposition on the original SQL and identify the statement type of the original SQL;

[0079] It's important to note that syntax parsing tools refer to specialized tools or components capable of performing syntax analysis and structural decomposition on SQL statements. Common tools include jsqlparser and ANTLR, whose core function is to transform unstructured SQL text into structured syntactic elements, supporting the parsing of mainstream SQL syntax (such as MySQL and Oracle SQL). Syntax decomposition refers to the process of using syntax parsing tools to break down the original SQL into independent syntactic elements such as field lists, value lists, keywords (such as INSERT and UPDATE), and conditional clauses (such as WHERE clauses), making the internal structure of the SQL clearly discernible. The statement type of the original SQL refers to the category categorized according to the SQL's function and syntactic structure. Common types include INSERT (data insertion), UPDATE (data modification), DELETE (data deletion), MERGE INTO (data merging), and SELECT (data query). Different types of SQL have fundamentally different syntactic structures and require targeted processing.

[0080] In one implementation, when calling the jsqlparser tool, the original SQL captured in step S21 is first used as the input parameter, and the original SQL is parsed into a Statement object (the core object representing the SQL statement in jsqlparser) using the CCJSqlParserUtil.parse method; then, the statement type of the original SQL is identified by the type judgment method of the Statement object (such as instanceof Insert, instanceof Update); finally, the syntax of different types of Statement objects is decomposed: for INSERT statements, getColumnNames (field list) and getItemsList (value list) are extracted; for UPDATE statements, getTable (table name), getSetItems (fields and values ​​in the SET clause), and getWhere (WHERE condition) are extracted, and the decomposed syntax elements are temporarily stored in the form of key-value pairs.

[0081] Additionally, it should be noted that the compatibility of the parsing tool determines the accuracy of the parsing: if the original SQL contains database dialect syntax (such as MySQL's LIMIT clause or Oracle's ROWNUM), a parsing tool that supports the corresponding dialect must be selected to avoid parsing failure due to syntax incompatibility; after parsing, the syntax elements must be validated (such as whether the length of the field list and value list in the INSERT statement is consistent). If there are syntax errors, the corresponding original SQL must be marked and reported to facilitate subsequent manual investigation.

[0082] Specifically, the original SQL statement to be processed is read from the storage location (such as memory cache or temporary log file) where the original SQL was temporarily stored in step S21. This original SQL statement is then passed as an input parameter to the parsing method of the syntax parsing tool (such as jsqlparser) to initialize the syntax parsing process. Next, syntax decomposition and statement type identification are performed: the syntax parsing tool breaks down the original SQL into independent syntax elements such as field lists, value lists, table names, and conditional clauses according to SQL syntax rules, generating structured syntax parsing objects (such as the Insert and Update objects of jsqlparser). The statement type of the original SQL (such as INSERT or UPDATE) is identified through the type judgment interface of the syntax parsing object.

[0083] Step S23: Based on the statement type of the original SQL, construct a syntax tree that is consistent with the syntax structure of the original SQL. The syntax tree includes a list of fields, a list of values, and logical relationship nodes of the original SQL.

[0084] It's important to note that a syntax tree is a model that uses a tree-like data structure to visualize the original SQL syntax logic. Each node corresponds to a syntax element of the SQL (such as a field node, value node, or logical relationship node), and the hierarchical relationship between nodes reflects the logical order of the SQL syntax. Field list nodes are nodes in the syntax tree that correspond to the original SQL field set, storing the names of all fields involved in the SQL (such as the field list of an INSERT statement or the fields in the SET clause of an UPDATE statement). Value list nodes are nodes that correspond to the original SQL value set, storing the specific numerical values ​​corresponding to the fields (such as the value list of an INSERT statement). Logical relationship nodes are nodes that correspond to logical associations in the SQL, such as the conditional logic (AND / OR) in the WHERE clause and table join logic (JOIN), reflecting the logical operation relationships in the SQL.

[0085] In addition, the node hierarchy of the syntax tree is consistent with the syntax precedence of the original SQL: for example, parenthetical conditions in the SQL, such as WHERE (AMOUNT>100 AND USER_ID='U100') OR ORDER_STATUS='PENDING', are represented in the syntax tree through the hierarchical nesting of "logical relationship nodes" (inner nodes correspond to the AND logic within the parentheses, and outer nodes correspond to the OR logic), ensuring that the syntax tree can accurately reflect the logical operation order of the SQL; after the syntax tree is built, it needs to be syntax validated to check the completeness of nodes (such as whether the INSERT statement contains field list and value list nodes) and the relevance of nodes (such as whether the number of fields and values ​​matches), so as to avoid logical defects in the constructed syntax tree.

[0086] Specifically, based on the original SQL statement type identified in step S22 (such as INSERT, UPDATE), and referring to the corresponding SQL syntax rules, the hierarchical relationship of the top-level node (such as the INSERT root node, UPDATE root node) and each level of child nodes (such as field list nodes, value list nodes, logical relationship nodes) of the syntax tree is defined to ensure that the node structure matches the SQL syntax logic. Then, the syntax tree nodes are constructed and populated with content: from the syntax elements decomposed in step S22, information such as table names, field lists, value lists, and logical conditions are extracted, and the information is filled into the corresponding nodes one by one according to the node hierarchy (such as filling field names into child nodes of field list nodes, and filling values ​​into child nodes of value list nodes); for SQL containing logical relationships (such as SQL with WHERE clauses), nested logical relationship nodes are constructed according to the logical operation order to ensure that the syntax tree fully reflects the logical relationships of the SQL. Finally, the syntax tree is validated: the completeness of the syntax tree nodes (such as whether necessary child nodes are missing) and the consistency of the node content (such as whether the number of fields matches the number of values) are checked to confirm that the syntax tree is completely consistent with the syntax structure of the original SQL, without any logical deviation.

[0087] This embodiment uses an SQL interceptor adapted to the software's data interaction framework to capture the original SQL executed by the software in real time and without omission. This avoids omissions in subsequent SQL adjustments due to incomplete interception. Furthermore, it uses a syntax parsing tool to break down and identify the statement type of the original SQL, enabling differentiated processing strategies for different types of SQL. This avoids syntax and logic confusion caused by indiscriminate processing. It then constructs a syntax tree containing field lists, value lists, and logical relationship nodes, transforming unstructured SQL text into a clear tree structure. When adding fields or adjusting logic later, nodes can be accurately located without directly modifying the SQL text, reducing the risk of syntax errors. Since the syntax tree is completely consistent with the original SQL syntax structure, it can fully preserve the original SQL's business interaction logic, ensuring that subsequent adjustments based on the syntax tree only add necessary fields and do not disrupt the software's original data operation functions.

[0088] In one feasible implementation, obtaining the update version information of the software to be updated includes:

[0089] Step S31: Receive the version update request instruction corresponding to the software to be updated. The version update request instruction includes the version update target, the scope of functional changes, and the data adjustment requirements.

[0090] It should be noted that version update request instructions refer to formal instruction documents or datasets initiated by business personnel, product personnel, or developers to define the content of software updates. Version update objectives refer to the core purpose to be achieved in this update, such as "adding customer VIP level management function," "optimizing order data synchronization efficiency," and "fixing customer information query errors," used to clarify the core value of the update. Function change scope refers to the software function modules or functional points involved in this update, such as "customer information editing module," "order status synchronization function," and "data statistics report function," used to define the boundaries of code modifications. Data adjustment requirements refer to the operational requirements for the software database in this update, such as "adding a VIP_LEVEL field to the customer table," "batch updating historical order status in the order table," and "deleting redundant product category tables," used to clarify the direction of changes to data structure or data content.

[0091] Specifically, a low-code platform is built with a requirement submission interface or API. Standardized input fields are set up to correspond to the elements of version update requirement instructions (version update target, scope of functional changes, and data adjustment requirements). Multiple input methods are supported, including text input, module selection, and table upload, adapting to different user habits. The system then receives version update requirement instructions submitted by users, automatically extracting the three core elements: update target, scope of functional changes, and data requirements. These elements are then validated for completeness, checking for missing key information (such as no update target or no selected scope of functional changes). Simultaneously, the data adjustment requirements are preliminarily validated for reasonableness (such as whether they contain explicit table or field names). Upon successful validation, a unique identifier (such as a requirement number) is assigned to the requirement instruction, and the instruction is stored in the requirement management database, providing a basis for subsequent queries.

[0092] For example, the software to be updated is an enterprise customer management system. Business personnel submit a version update request through the low-code platform's requirement interface: the version update target is "to add a customer VIP level management function, supporting filtering customers by VIP level"; the scope of function changes is selected as "customer information editing module" and "customer list query module"; the data adjustment requirements are described as "adding a VIP_LEVEL field (VARCHAR(10)) to the customer table (CUST_INFO), and adding 'Gold' and 'Platinum' level records to the customer level dictionary table (CUST_VIP_DICT)". The system verifies that the instructions are complete, assigns the requirement number REQ20251010, and completes the receipt of the requirement instructions.

[0093] Step S32: Based on the version update target, retrieve the basic version information of the software to be updated from the version management repository. The basic version information includes the basic code library and the basic database table structure.

[0094] It should be noted that a version control repository refers to a centralized storage system used to store software version code, database structure, documents, and other resources. Common types include Git and SVN, which have functions such as version tracking, branch management, and access control to ensure the security and reusability of software version resources. The basic version information of the software to be updated refers to the core resource set contained in the current stable base version of the software to be updated. It is the development foundation for this update and avoids the inefficiency caused by building from scratch. The basic code repository refers to the complete source code set of the software in the basic version, including code files, configuration files, dependency package lists, etc. of all functional modules. For example, the basic code repository of the customer management system includes files such as "Customer Information Editing.java" and "Customer Query.js". The basic database table structure refers to the table definition information of the software database in the basic version, including table name, field name, field type, primary key, foreign key, index, etc. For example, the basic table structure of the customer table (CUST_INFO) includes field definitions such as CUST_ID (primary key, VARCHAR(20)), CUST_NAME (VARCHAR(50)), and CREATE_TIME (DATETIME).

[0095] Additionally, it should be noted that if the software to be updated has multiple modules or branches, the base version must be accurately matched based on the update target. For example, if the software includes a "Customer Management Branch" and an "Order Management Branch," and the update target is customer-related functions, only the base version of the "Customer Management Branch" should be retrieved to avoid resource redundancy caused by retrieving unrelated branches. After retrieving the base version information, a secondary matching and verification with the version update target is required. For example, if the update target involves "adding new fields to the customer table," it is necessary to confirm whether the base database table structure contains the customer table. If it is missing, a prompt will be displayed indicating that the requirement instruction has been adjusted or the version selection is incorrect.

[0096] Specifically, based on the version update target in step S31, determine the unique identifier of the software to be updated (such as software name, system ID); query all historical versions and branches of the software in the version management repository, and select the version that is currently running stably (such as in production environment) and can support the achievement of the update target as the base version (prioritizing the latest stable version). Then, use the client tools or commands of the version management repository to pull the complete source code (including all functional module code, configuration files, and dependency list) corresponding to the base version to the local machine or development server, ensuring that the code files are complete and undamaged; simultaneously download the code dependency package list of the base version to provide a dependency basis for subsequent code compilation and execution. Finally, obtain the database table structure script file corresponding to the base version from the version management repository, or connect to the database instance corresponding to the base version through a database connection tool, and export the structure definition of all related tables (including field names, field types, primary keys, foreign keys, and indexes); organize the table structure information into a standardized format, associate it with the base code library for storage, and form complete base version information.

[0097] Step S33: Filter out the code blocks to be updated according to the scope of the functional changes, and generate the SQL to be updated according to the data adjustment requirements;

[0098] It should be noted that the code block to be updated refers to the code snippets selected from the base code library that are directly related to the scope of the functional change. It includes class files, method logic, front-end page code, etc. required to implement the target function. The code block to be updated only contains the parts that need to be modified, not the entire code.

[0099] In addition, each code block to be updated must be associated with a unique identifier: assign a code task identifier corresponding to the scope of the functional change to each code block to facilitate subsequent location of the code and tracing of related functions; the SQL to be updated must match the functional logic of the code block to be updated. For example, when adding VIP level input logic to the "Customer Information Editing Code Block", the SQL to be updated must include the statement "Add VIP_LEVEL field to the customer table" to ensure that there is a corresponding data field to support the code after the modification.

[0100] Specifically, the scope of functional changes in step S31 is broken down into specific functional module paths and functional points; the basic code library retrieved in step S32 is traversed to locate all code files under that path; code files directly related to the changes are selected based on the functional points, and code fragments that need to be modified (such as methods and page components) are further extracted from these files; a unique code task identifier is assigned to the selected code fragments, marking them as code blocks to be updated, and they are stored in association with the scope of functional changes. Next, the data adjustment requirements in step S31 are analyzed, distinguishing between table structure adjustments (such as adding fields or creating tables) and data content adjustments (such as adding or modifying data); for table structure adjustments, corresponding DDL statements (such as ALTER TABLE and CREATE TABLE) are generated to ensure that field types and constraints match the requirements; for data content adjustments, corresponding DML statements (such as INSERT and UPDATE) are generated to ensure that data values ​​conform to business rules; all generated SQL statements are subjected to syntax validation (such as through database syntax checking tools or execution in a test environment), and those that pass the validation are marked as SQL to be updated and stored in association with the data adjustment requirements.

[0101] Step S34: Integrate the code block to be updated with the SQL to be updated to form the version information to be updated.

[0102] Specifically, a standardized directory structure is created, including code storage, SQL storage, and version descriptions, clearly defining the function and storage rules of each directory / file (e.g., code is categorized by task identifier, and SQL by type). The code blocks to be updated from step S33 are then categorized by code task identifier and code type (e.g., backend Java, frontend Vue) and stored in the code directory, generating a code list to record code block details. The SQL to be updated is categorized by statement type (DDL, DML) and stored in the SQL directory, generating an SQL list to record SQL details. Each resource file is ensured to have a clear identifier and description for easy subsequent retrieval. Finally, the version description file is filled with metadata such as version update target, requirement instruction number, base version identifier, and resource quantity, clarifying the relationship between code blocks and SQL. The entire version information package is then subjected to integrity verification, checking whether the code blocks and SQL are complete and whether the relationships are clear. After successful verification, the version information package is compressed and assigned a unique version identifier, forming the final version information to be updated.

[0103] This embodiment clearly defines the core direction and specific content of this update, preventing the expansion of the update scope or the omission of key content due to unclear requirements. It retrieves basic version information from the version management repository to ensure that the content to be updated is developed based on the existing software foundation, avoiding compatibility issues caused by deviating from the original architecture, maintaining the continuity of version iteration, and then selecting the code blocks to be updated according to the scope of functional changes to avoid full code modification; it generates the SQL to be updated according to data adjustment requirements to ensure that data operations match functional requirements, reduce ineffective development and redundant operations, and improve update efficiency.

[0104] In one feasible implementation, the step of updating the syntax tree and transforming it to generate the target SQL based on the SQL to be updated includes:

[0105] Step S41: Parse the SQL to be updated and extract the target fields contained in the SQL to be updated. The target fields include the change version number field, the operation type field, and the release status field.

[0106] It's important to note that the target fields refer to a specific set of fields used for data change tracking and version management. The change version number field records the update batch to which the data belongs, distinguishing different versions of the data. The operation type field marks the data change behavior, with common values ​​including codes for "added," "modified," and "deleted." The release status field indicates whether the data has been deployed to the production environment, with common values ​​including codes for "not released" and "released." These three types of fields have completely consistent field types across all database tables in the software to be updated, ensuring the universality of version management logic.

[0107] It should also be noted that the SQL to be updated may contain various statement types (such as ALTER TABLE and INSERT), but regardless of the type, the logic for extracting the target field remains consistent: if it is an ALTER TABLE statement (table structure adjustment), the target field is directly extracted from the field addition list; if it is an INSERT statement (data addition), the target field is searched from the field list; if the SQL to be updated does not contain the target field, the definition logic of the target field is automatically added to ensure that subsequent data operations all carry version management identifiers and avoid situations where some data lacks version information.

[0108] Specifically, the process involves obtaining a set of SQL statements to be updated, inputting them into an SQL syntax parsing tool (such as jsqlparser), configuring parsing rules (such as supported SQL dialects and field recognition rules), and starting the syntax parsing process. The parsing tool then breaks down the SQL statements to be updated into structured elements such as table names, field lists, and statement types. Fields that match the target field definitions (version number, operation type, and release status fields) are selected from the field list. If the SQL statement to be updated does not contain a target field, the definition logic of the target field is automatically supplemented according to version management rules (such as appending the target field to the field list). The names and data types of the target fields are recorded to form a target field list. Finally, the completeness of the target fields is verified: the target field list is checked to ensure that the version number, operation type, and release status fields are included. If any are missing, prompts are given to supplement them to ensure that no target fields are omitted.

[0109] Step S42: Based on the statement type corresponding to the original SQL, locate the relevant nodes in the syntax tree related to the target field, insert the target field into the relevant nodes in the syntax tree, and simultaneously supplement the value information corresponding to the target field;

[0110] It's important to note that the relevant nodes associated with the target field refer to the nodes in the syntax tree used to store field information, such as the "field list node" and "value list node" for INSERT statements, and the "SET clause node" for UPDATE statements. These nodes indicate the precise location where the target field is inserted. The value information corresponding to the target field refers to the specific numerical value that matches the target field. Specifically, the version number field represents the version identifier of this update (e.g., V2.2.0), the operation type field represents the data change behavior code corresponding to the original SQL (e.g., "1" for INSERT, "2" for UPDATE), and the publication status field represents the initial status code (e.g., "0" represents unpublished). All values ​​must be consistent with the data type of the target field.

[0111] The core objective of this step is to accurately integrate version management fields into the SQL structure without disrupting the original SQL business logic: by locating relevant nodes according to statement type, ensuring that the insertion position of the target field conforms to SQL syntax rules, avoiding syntax confusion caused by incorrect insertion position; and synchronously supplementing value information so that the target field not only has a definition but also carries actual data related to version updates, ensuring that version management information can be written correctly when executing SQL later, achieving traceability of data changes, and avoiding format errors or logical deviations that may occur when manually modifying SQL text.

[0112] Additionally, it should be noted that the insertion order of the target fields must follow a uniform rule: regardless of the type of the original SQL statement, the version number field, operation type field, and release status field should be inserted into the relevant nodes in a fixed order (e.g., version number first, release status second) to ensure that the version management fields of all SQL statements are in the same order, which facilitates subsequent data querying and analysis; after inserting the target fields, the hierarchical relationship of the syntax tree nodes should be checked to ensure that the newly added nodes are logically consistent with the original nodes and do not disrupt the syntax structure of the original SQL.

[0113] Specifically, based on the statement type of the original SQL (e.g., INSERT, UPDATE), a mapping table is formed by pre-setting the node types related to the target field in the syntax tree (e.g., field list node and value list node for INSERT; SET clause node for UPDATE). The syntax tree is then traversed, and the nodes related to the target field are found according to the mapping table, marking their positions (e.g., the end of the field list node, the append position of the SET clause node). Next, the change version number, operation type, and release status field name are inserted at the marked node positions. The version identifier is obtained from the version update configuration, the operation type code is mapped according to the statement type, and the default release status code is set as the value information corresponding to the target field, supplementing the corresponding value nodes in the syntax tree (e.g., value list node, SET clause value position), ensuring a one-to-one correspondence between fields and values. Finally, the syntax tree nodes after inserting the target field are verified to ensure that the new field has no logical conflicts with the original fields (e.g., duplicate field names, mismatched value types), ensuring the integrity of the syntax tree structure. For example, for modifying the syntax tree structure using the INSERT statement, please refer to [reference needed]. Figure 2 .

[0114] Step S43: Perform syntax validation on the updated syntax tree. If the validation passes, convert the syntax tree back into executable target SQL.

[0115] It should be noted that the updated syntax tree refers to the syntax tree after inserting the target field and supplementary value information in step S42. It contains the business logic of the original SQL and the logic of the newly added version management fields, and is the object of syntax validation and transformation. The executable target SQL refers to the SQL statement generated by re-transforming the syntax tree that has passed syntax validation, which can be directly executed in the database. It retains the business logic of the original SQL and also contains the change version number, operation type, release status fields and corresponding value information. The syntax is complete and the logic is correct.

[0116] Specifically, the SQL syntax validation tool is invoked to load the updated syntax tree and perform a full check according to preset validation rules (consistency of field and value quantity, data type matching, keyword correctness, and naming conventions). Errors found during the validation process are recorded, specifying the error location (e.g., a mismatch between a field and value in a node) and the error type (e.g., type incompatibility), and modification suggestions are generated. If errors exist, the process returns to step S42 to adjust the syntax tree; otherwise, it proceeds to the next step. Next, the syntax tree conversion tool is invoked to convert the syntax-validated syntax tree into target SQL in text format according to SQL syntax rules (e.g., the corresponding order of field and value lists, and the format of the SET clause). Comments are added to the target SQL explaining the purpose of the newly added target fields. The converted target SQL ensures that it retains the business logic of the original SQL while fully including version management fields and value information. Finally, the target SQL is executed in the test database to check if data operations (e.g., inserting and updating data) can be completed normally, verifying that the target field values ​​are correctly written to the database. If execution is successful, the target SQL is confirmed to be executable; if execution fails, the syntax tree is adjusted based on the error message, and the validation and conversion process is re-executed until the target SQL can be executed normally.

[0117] When generating SQL files, they are generated table-by-table, meaning one table, one file. Within each SQL file, special comments serve as data delimiters, such as "--data delimiter". UK comment lines store the data ID or unique key for that row. When a SQL file generated for a particular table conflicts with SQL files in the Git repository, the following methods are used to identify data changes:

[0118] <1> Retrieve all UKs of the Git repository files, denoted as GIT_UK_LIST, and retrieve all UKs of the latest generated SQL file, denoted as NEW_UK_LIST;

[0119] <2> If UK∈GIT_UK_LIST and UK∈NEW_UK_LIST, then the data is modified.

[0120] <3> When UK If GIT_UK_LIST contains UK∈NEW_UK_LIST, then it is newly added data;

[0121] <4> When UK∈GIT_UK_LIST and UK NEW_UK_LIST indicates that data has been deleted.

[0122] Based on the data changes, regenerate the final SQL file, which will be the correctly merged file.

[0123] This embodiment locates relevant nodes in the syntax tree based on the original SQL statement type, ensuring that the insertion position of the target field matches the SQL syntax logic. This avoids syntax errors caused by misplaced field insertions, guarantees the correctness of the SQL structure, and simultaneously supplements corresponding value information when inserting the target field. This ensures that the value information matches the business requirements of the version to be updated, preventing SQL execution failures caused by fields having definitions but no values. This achieves deep binding between fields and version update logic, thereby validating the updated syntax tree and identifying syntax errors in advance. After successful validation, it is converted into executable target SQL, avoiding syntax vulnerabilities caused by directly modifying the SQL text, ensuring that the target SQL can be executed normally, and improving the stability of database operations.

[0124] In one feasible implementation, determining the code location of the original code block and generating the target code based on the code task identifier of the code block to be updated includes:

[0125] Step S51: Establish a code task association table for the software to be updated. The code task association table records the storage path, module affiliation, and dependency relationship between the code task identifier and the original code block.

[0126] It's important to note that the code task association table is a structured data table that stores the correspondence between code task identifiers and original code blocks. It serves as the core link between code tasks and specific code resources, supporting rapid code location later. The code task identifier is a unique identifier (which can be a string or number) assigned to each code update task, used to distinguish different code change requirements and ensure accurate association between tasks and code. The original code block refers to the unmodified existing code fragments in the software to be updated that are related to the code task, including backend class files, frontend page code, configuration files, etc., and forms the basis for embedding the code block to be updated. The storage path refers to the specific storage location of the original code block in the software code repository, used to directly locate the code file; module affiliation refers to the software functional module to which the original code block belongs (such as a customer information management module or an order processing module), used to define the business scope of the code; and dependencies refer to the external resources or other code modules required for the original code block to run (such as dependencies on database connection modules or logging utility classes), used for subsequent code compatibility checks.

[0127] Additionally, it should be noted that the code task association table needs to be maintained in real time as the software code is updated: when a new code module is added or a redundant code block is deleted, the storage path, module affiliation, and dependency relationship in the association table must be updated synchronously to avoid location errors caused by outdated association information; if the dependency relationship of the original code block changes (such as replacing the dependent log utility class), the "dependency relationship" field in the association table must also be updated in a timely manner to ensure the accuracy of subsequent dependency checks.

[0128] Specifically, the codebase of the software to be updated is traversed, and all original code blocks that may be involved in the update are selected according to the directory structure and functional logic. The storage path (accurate to the file level) and the functional module to which each original code block belongs (such as customer management or order management) are recorded. By analyzing import statements and configuration file references in the code, the dependent modules or resources required for the original code block to run are identified and compiled into a dependency list. Then, a structured storage format (such as a database table) is adopted to define core fields such as "code task identifier", "storage path", "module affiliation", and "dependency". A unique code task identifier is assigned to each original code block (if there is an existing task, the identifier is reused; if a new task is added, a new identifier is generated). The storage path, module affiliation, and dependency list of the original code block are filled into the association table one by one to ensure that each record corresponds one-to-one with the original code block. Finally, the association table is checked for missing storage paths, ambiguous module affiliations, or unrecorded dependencies. If any are found, they are supplemented and improved. The query function of the association table is tested to ensure that the corresponding original code block information can be quickly found by the code task identifier, thus completing the establishment of the code task association table.

[0129] Step S52: Match the code task identifier of the code block to be updated with the code task association table to determine the code location of the original code block;

[0130] It should be noted that the core purpose of this step is to avoid blindly searching for original code in a large codebase by accurately matching code task identifiers, thus greatly improving the efficiency of code location; and to obtain the storage path of the original code block based on the association table, ensuring that the located code block completely matches the functional requirements of the code block to be updated, avoiding code modification deviations caused by incorrect location, and providing accurate code resources for subsequent extraction of code logic framework and checking of dependencies.

[0131] In addition, code task identifier matching supports fuzzy search and batch matching: if the code block to be updated involves multiple related tasks (such as modifying customer editing and customer query functions at the same time), multiple code task identifiers can be entered for batch search to obtain the code locations of multiple original code blocks at once; if there is some memory bias in the code task identifier (such as only remembering the date and function abbreviation), relevant records can be filtered out through fuzzy search, and the target code location can be further confirmed to improve the matching flexibility.

[0132] Specifically, the associated code task identifier is read from the metadata information of the code block to be updated (such as code file header comments and low-code platform task configuration), ensuring that the identifier format is consistent with the records in the code task association table. The extracted code task identifier is then used as the query keyword to perform a query operation in the code task association table. Matching records are filtered based on the query results. If multiple records exist, a second filtering is performed, combining the functional description of the code block to be updated (such as "customer information editing") with the module affiliation in the record, to determine a unique target record. Finally, the "storage path" field is extracted from the target record; this path represents the specific location of the original code block in the code repository. Navigation to the corresponding code file is performed based on the storage path, verifying whether the code logic in the file matches the functional requirements of the code block to be updated. Once confirmed, the location of the original code block is determined.

[0133] Step S53: Extract the code logic framework of the original code block, and embed the functional code fragments in the code block to be updated into the code logic framework to form preliminary target code;

[0134] It's important to clarify that the code logic framework refers to the structural skeleton of the code after extracting the specific business logic from the original code block. This includes core structural elements such as class definitions, method declarations, parameter lists, return types, dependency references, and global variable definitions, but does not contain the specific execution logic within the methods. Its purpose is to provide a standardized embedding interface for the code block to be updated. The functional code snippets within the code block to be updated refer to the core code used to implement specific functional changes, such as the assignment logic for new fields or optimized query condition processing code. These only contain the business logic within the methods and do not include framework content such as class definitions and method declarations. The preliminary target code refers to the code formed after embedding the functional code snippets into the code logic framework, which has not yet been validated. It contains the structural skeleton of the original code and the functional logic to be updated, and serves as the basis for subsequent validation and optimization.

[0135] The core objective of this step is to integrate new functional logic while preserving the stability of the original code structure: by extracting the code logic framework, we can avoid the code blocks to be updated from disrupting the overall structure of the original code (such as class definitions and method parameters), thus ensuring the consistency of the code system; by embedding functional code fragments into the framework, we can achieve seamless integration of the new logic with the original structure, avoid code logic conflicts or structural chaos, reduce redundant operations of full code modification, and improve code update efficiency.

[0136] In addition, the extraction of code logic framework must follow language syntax specifications: for example, Java code must retain access modifiers (public / private) and method parameter types, and Vue code must retain component options (data, methods) to avoid errors in subsequent embedded code due to incomplete framework extraction; the embedding position of functional code snippets must match the business logic order of the original code. For example, in the backend "save customer information" method, the "VIP level assignment" logic must be embedded before "customer information entry" to ensure the rationality of the business logic.

[0137] Specifically, the syntax structure of the original code blocks is analyzed, identifying and preserving framework elements such as class definitions, method declarations, parameter lists, return types, dependency references, and global variables. Specific business logic code within methods and hook functions is deleted, retaining only empty code structures (such as method bodies and hook function bodies) to ensure the framework conforms to the syntax of the programming language. Preliminary syntax validation is performed on the framework to check for structural omissions (such as missing method parentheses or missing dependency references) to ensure the framework can be correctly embedded. The embedding position of the functional code snippets within the code logic framework is then determined (e.g., inside the backend method body or in a designated area of ​​the frontend template). This position must match the order of business logic (e.g., data processing logic is embedded before data storage). The functional code snippets from the code blocks to be updated are embedded line by line into the corresponding positions in the framework. If a snippet involves new parameters (e.g., vipLevel), the parameter definition is simultaneously added to the framework's method declaration. After embedding, the code syntax format is checked (e.g., matching parentheses, semicolon endings) to ensure seamless integration of the new logic with the framework structure, forming the initial target code.

[0138] Step S54: Perform dependency checks and syntax corrections on the preliminary target code, determine whether the preliminary target code is compatible with the existing code structure of the software to be updated, and generate the target code.

[0139] It's important to note that dependency checking refers to the process of verifying the existence and availability of external resources required for the initial target code to run. The purpose is to prevent runtime errors due to missing dependencies, such as checking whether necessary database connection classes and front-end component libraries have been imported. Syntax correction refers to identifying and fixing syntax errors in the initial target code using tools or rules, such as undefined variables, mismatched parentheses, misspelled keywords, and missing semicolons, ensuring the code conforms to the programming language's syntax rules. The existing codebase of the software to be updated refers to the set of code that is already running stably in the software to be updated, including code style (such as naming conventions and code indentation), architectural design (such as layered structure and module division), and interface definitions (such as method parameter formats and return value types). This serves as the benchmark for compatibility assessment. Compatibility refers to the degree of matching between the initial target code and the existing codebase in terms of syntax, architectural logic, and interface interactions. If they match, they can be seamlessly integrated into the existing code; otherwise, adjustments are required.

[0140] The core purpose of this step is to ensure the usability and stability of the final code: through dependency checks and syntax correction, we can identify basic problems in the code's operation in advance and prevent these problems from being left over to the deployment stage and causing functional failures; through compatibility verification, we can ensure that the new code can be seamlessly integrated into the existing code system without disrupting the normal operation of the original software functions, while conforming to the software's code specifications and architecture design, facilitating subsequent maintenance and iteration, and solving the problem of "conflict between new code and old system" in traditional code updates.

[0141] Specifically, a code dependency analysis tool is invoked to scan the dependency references in the initial target code, identifying missing dependency resources (such as classes, JAR files, and components). For missing dependencies, the installation path is automatically suggested or they are imported from the software's public dependency library to ensure all dependency resources are available. The dependency check results are recorded, and fixed dependency issues are marked. Next, a code syntax checker is used to scan the initial target code according to programming language specifications, identifying syntax errors (such as undefined variables or mismatched parentheses). Errors that can be automatically corrected (such as adding semicolons or correcting spelling) are automatically fixed, while errors that cannot be automatically corrected (such as logical errors) generate error reports prompting manual correction. After correction, the code is rescanned to ensure no syntax errors remain. Next, compatibility verification is conducted: the code style (naming, indentation), architectural logic (layering, modules), and interface interactions (parameters, return values) of the initial target code are checked against the existing code structure of the software to be updated. If incompatibility issues exist (such as parameter mismatches or violations of layering logic), the code is adjusted (such as modifying parameters or refactoring code locations). After successful verification, the overall logic of the code is checked again to ensure that the functional changes can be implemented normally. Finally, the target code is generated: integrating all the inspection and adjustment results to form target code that is syntactically correct, has complete dependencies, and is compatible with the existing code system.

[0142] This embodiment records information such as the code task identifier, the storage path of the original code block, and module affiliation through a code task association table. This avoids blindly searching for code, quickly locates the original code, and improves code location efficiency. Furthermore, by extracting the code logic framework of the original code block (retaining the skeleton of classes, methods, etc.), only the code fragments of the function to be updated are embedded, avoiding damage to the overall structure of the original code and reducing logical confusion caused by code refactoring. In addition, dependency checks are used to supplement missing references, syntax errors are corrected to fix formatting errors, and compatibility verification is performed to ensure that it matches the existing code system. This proactively identifies code problems and avoids functional errors or dependency conflicts after deployment.

[0143] In one feasible implementation, the step of performing version updates and testing on the software to be updated based on the target SQL and the target code to complete the version update task includes:

[0144] Step S61: Deploy the target code to the code module corresponding to the software to be updated, replace the original code block, and form the software version with updated code;

[0145] It should be noted that the code modules corresponding to the software to be updated refer to the functional modules within the software related to the target code's functionality, ensuring that the target code is deployed to the correct business scope. The original code is the replacement object for the target code; after replacement, the original code block is temporarily stored in the version control repository for easy rollback later. The software version after the code update refers to a temporary software version formed after the target code is deployed. It only runs in the test environment for subsequent integration testing and does not affect production environment services.

[0146] In addition, target code deployment supports incremental deployment: if the target code is only partially modified from the original code block (such as adjusting the internal logic of a method), only the modified part of the code file will be replaced, rather than the entire file, reducing the amount of deployment data and time consumption; after deployment is completed, deployment logs must be recorded, including the version identifier of the target code, deployment time, path of the original code block to be replaced, compilation results, and other information.

[0147] Specifically, first connect to the test environment server of the software to be updated, and confirm that the server's code module storage path and compilation tools (such as Maven and npm) are configured correctly. Download the target code from the version control repository, categorize it by code type (backend, frontend), and ensure that the target code files match the file structure of the module to be updated. Then, perform target code deployment and replacement: using automated tools or scripts, upload the target code files to the storage path of the corresponding code module, overwriting and replacing the original code block files; before replacement, automatically back up the original code blocks to the historical branch of the version control repository, and set the backup file identifier (such as the original code block file name + backup time). Next, execute the code compilation command on the test environment server to check whether the target code can be compiled normally. If there are compilation errors (such as missing dependencies or syntax errors), fix the problems according to the error messages (such as installing dependencies or correcting the code) and recompile. After successful compilation, start the software testing service to verify that the module containing the target code can be loaded normally without startup errors. Finally, confirm that the software testing service is running normally, the functional modules corresponding to the target code are accessible, and mark the current software status as "software version after code update".

[0148] Step S62: Execute the target SQL in the test database of the software to be updated to complete the database table structure adjustment and data update, forming the updated database version;

[0149] It should be noted that the test database refers to a database instance used to simulate the production environment and support software testing. Its configuration (such as database type, version, and initial table structure) is consistent with the production environment, but the data is test data to avoid affecting production business data. The updated database version refers to the test database state after the target SQL is executed, where the table structure and data content have been adjusted. This state is matched with the updated software version and is used for subsequent integration testing.

[0150] In addition, the target SQL execution supports transaction control and batch execution: if the target SQL contains multiple statements, it can be encapsulated into a transaction (such as through BEGIN TRANSACTION, COMMIT). If the execution of a certain statement fails, the entire transaction will be rolled back to avoid the database being in a partially updated state. If the DML statement involves a large amount of data (such as batch updating 100,000 historical data records), a batch execution method is adopted (such as executing UPDATE statements in segments by ID) to avoid a single execution consuming too many database resources and causing execution timeout.

[0151] Specifically, confirm that the test database instance of the software to be updated is running normally, and that the database type (e.g., MySQL, Oracle), version, and syntax are compatible with the target SQL. Obtain the target SQL file from the version control repository, organize the SQL statements according to the execution order (DDL first, DML last), and label the purpose of each statement (e.g., "DDL: Add VIP field to customer table"). Then, connect to the test database using a database connection tool or automated script, execute the target SQL statements, prioritizing DDL statements (table structure adjustments), and monitor the execution status in real time. If table structure conflicts occur (e.g., a field already exists), adjust the target SQL (e.g., modify field comments or delete duplicate ALTER statements) and re-execute. After the DDL statements are executed, query the table structure to confirm the adjustment results (e.g., whether the field was added successfully, whether the field type is correct). Next, execute the DML statements (data updates), and query the corresponding table data to verify whether the data changes meet expectations (e.g., whether the added data exists, whether the modified data values ​​are correct).

[0152] If a target SQL statement fails to execute (e.g., primary key conflict, data type mismatch), locate the problem based on the database error message (e.g., check for duplicate data, field type mismatch). If the executed SQL statement is a transaction-encapsulated SQL statement, roll back the transaction directly. After fixing the problem (e.g., deleting duplicate data, correcting the SQL statement), re-execute the SQL statement to ensure all target SQL statements execute successfully. Finally, create an updated version: confirm that all target SQL statements have executed successfully, test that the database table structure and data meet expectations, and mark the current database status as "updated database version".

[0153] Step S63: Perform joint debugging tests on the software version after code update and the database version after data update. The joint debugging tests include functional testing, performance testing and compatibility testing.

[0154] It's important to note that integration testing refers to combining two versions to verify the correctness of the software code's interaction logic with the database. By simulating real-world business scenarios, it checks the collaborative capabilities of the code and data, avoiding issues that cannot be exposed by testing the code or data alone. Functional testing verifies whether the functions corresponding to the target code can be implemented normally and whether the business logic is correct. For example, testing whether the "Customer VIP Level Editing" function can successfully save VIP levels to the database and whether it can be displayed correctly during queries. Performance testing verifies the software's response speed and resource consumption when handling concurrent requests and large amounts of data. For example, testing whether the software's response time is within a preset threshold (e.g., 1 second) and whether the server CPU utilization is below 80% when 100 users are editing customer VIP levels simultaneously. Compatibility testing verifies the software's adaptability in different operating environments (e.g., different browsers, different operating systems) and when interacting with other related modules. For example, testing whether the customer VIP level function can be used normally in Chrome and Firefox browsers and whether it is compatible with the "VIP Order Discount" logic of the order management module.

[0155] For details, please refer to steps S71-S74, which will not be repeated here.

[0156] Step S64: If the test fails, adjust the target code and the target SQL according to the test error message, and re-execute the integration test until the test passes.

[0157] It should be noted that "test failure" refers to issues such as functional errors, substandard performance, or compatibility problems found during the integration testing in step S63, causing the version to fail to meet deployment requirements. Test error messages refer to key information recorded during the testing process used to locate problems, including the error location, error type, and error triggering conditions.

[0158] Specifically, extract the error location, type, and triggering conditions to pinpoint the root cause of the problem (whether it's a code issue or an SQL issue). For example, if the error location is in a code method and the type is a functional error, prioritize investigating the target code; if the error location is in a database operation and the type is a syntax error, prioritize investigating the target SQL.

[0159] Furthermore, if the issue is a code problem (such as missing fields in a query), modify the logic of the target code (such as adding fields to the query or optimizing parameter passing); if the issue is an SQL problem (such as incorrect field names), correct the statement in the target SQL (such as correcting field names or adding missing field definitions); after adjustments, perform partial verification (such as testing the modified code method separately or executing the adjusted SQL) to ensure that the problem is initially resolved, and re-execute the integration test until the integration test passes, ensuring that the version has no known defects.

[0160] Step S65: If the test passes, the target code and the target SQL are synchronously deployed to the production environment of the software to be updated, thus completing the version update task.

[0161] It should be noted that "test passed" means that the integration testing (functional, performance, and compatibility testing) in step S63 was error-free, the target code and target SQL could work together to achieve the expected functionality, and met performance and compatibility requirements, making the version ready for deployment. The production environment refers to the official operating environment in which the software to be updated provides services, including real business data and core server resources. Deployment operations directly affect user experience and require strict control. The version update task refers to the entire process from the submission of version requirements to the completion of production deployment. Completion of this step marks the official end of the task, and the software enters the new version's operational phase.

[0162] Specifically, a deployment plan is developed, including deployment time, steps, and rollback contingency plans; the original code in the production environment is backed up (to the historical branch of the version control repository) and the production database data (full backup) to ensure recovery in case of deployment failure; the servers, databases, and dependent components in the production environment are confirmed to be running normally and without any risk of failure. Then, the target code is deployed to the corresponding code module in the production environment using automated tools, replacing the original code block, and the code loading status is monitored during the deployment process; simultaneously, the target SQL is executed in the production database using database tools, following the order of "DDL statements (table structure adjustment) → DML statements (data update)," and the SQL execution results are monitored; after both deployments are completed, the software service in the production environment is restarted to ensure that the target code and SQL are effective. Next, the target functional module in the production environment (such as the customer VIP level editing page) is accessed, and key operations (such as saving and querying) are performed to check whether the function is normal, while verifying the correctness of the table structure and data in the production database; if no anomalies are found, a deployment success log is recorded; if anomalies are found, the rollback contingency plan is immediately executed to restore the original code and database data to avoid impacting business operations. Finally, after confirming that the production version is running stably (e.g., no anomalies are detected after 24 hours of monitoring), notify relevant business personnel that the new version has been launched, mark the version update task as officially completed, and archive the deployment plan, backup data, and deployment logs for future traceability.

[0163] This embodiment first deploys the target code to replace the original code block, and then executes the target SQL to adjust the database. This ensures that software function changes and data structure adjustments are implemented synchronously, avoiding version anomalies caused by "code updates without data adaptation" or "data updates without code compatibility". Furthermore, it completes integration testing in the test environment, discovering code logic defects, database operation errors, or performance bottlenecks in advance, avoiding failures caused by direct deployment to the production environment, and improving version stability. After the test is passed, the target code and target SQL are synchronously deployed to the production environment to avoid functional failures caused by asynchronous deployment. At the same time, it ensures that the production environment version is completely consistent with the version that has passed the test and verification, guaranteeing the normal operation of the business.

[0164] In one feasible implementation, the joint debugging test between the updated software version and the updated database version includes:

[0165] Step S71: Construct a test environment consistent with the production environment of the software to be updated. The test environment includes servers, databases, and dependent components with the same configuration.

[0166] It should be noted that the test environment refers to a simulated environment built to verify the effectiveness of version updates. Its core requirement is complete consistency with the production environment to avoid distorted test results due to environmental differences. Identical server configuration means that the test environment server's CPU, memory, disk, operating system version, network bandwidth, and other parameters are completely matched to the production environment server. Identical database configuration means that the database type (e.g., MySQL, Oracle), version number, initial table structure, index configuration, and permission settings are consistent with the production environment, and the test data must simulate the distribution characteristics of production data (e.g., data volume, data format). Identical dependency components refer to the middleware (e.g., Tomcat, Nginx), third-party libraries (e.g., Java JAR packages, frontend npm packages), and interface services (e.g., test versions of payment and SMS interfaces) required for software operation, with versions completely identical to those in the production environment.

[0167] In addition, the test environment must be resettable: before each integration test, the test environment can be quickly restored to its initial state (such as resetting database data or rolling back code versions) to avoid residual data or code modifications from the previous test affecting the results of subsequent tests; at the same time, the test environment needs to be configured with monitoring tools (such as Zabbix or Prometheus) to monitor server resource usage and database running status in real time, providing data support for subsequent performance tests.

[0168] Specifically, a baseline environment configuration table is created by compiling a list of server configurations for the production environment (CPU model, memory size, operating system version), database configurations (type, version, table structure, indexes), and dependent components (middleware version, third-party library version, interface address). Based on this table, test servers with identical production configurations are procured or requested; the same operating system, middleware, and dependent components as the production version are installed; the database is deployed and anonymized test data is imported; and mock services are set up to replace third-party interfaces in the production environment. Next, configuration comparison tools are used to verify the server parameters, component versions, and database structure of the test and production environments item by item; basic functional tests (such as software startup and database connection) are run to verify environment availability. Finally, once all configurations are confirmed to be consistent with the production environment, the test data matches the production data, and dependent components can be called normally, the test environment is marked as successfully set up, providing a foundation for subsequent test case execution.

[0169] Step S72: Design a test case set for the scope of functional changes in the software to be updated. The test case set includes normal scenario test cases, abnormal scenario test cases, and boundary scenario test cases.

[0170] It should be noted that the scope of functional changes refers to the functional modules or points to be modified as defined in the version update requirement instruction. A test case set refers to a collection of test cases designed for the scope of functional changes. Each test case contains three core elements: input conditions, operation steps, and expected results, used to verify whether the software functionality meets the requirements. Normal scenario test cases simulate routine user operations, inputting valid data and executing standard procedures to verify the basic correctness of the function; abnormal scenario test cases simulate user errors or system anomalies, inputting invalid data or triggering abnormal procedures to verify the software's fault tolerance; boundary scenario test cases simulate scenarios with extreme values ​​of functional parameters to verify the stability of the software under boundary conditions.

[0171] Specifically, the scope of functional changes in the version update requirements is broken down into the smallest testable business scenario units, clearly defining the core functions and business logic of each unit. Then, for each business scenario unit, test cases are designed for normal scenarios (verifying functional correctness under valid input), abnormal scenarios (verifying the fault tolerance of invalid input and abnormal processes), and boundary scenarios (verifying the stability under boundary conditions such as parameter limits and high concurrency). Each test case must clearly define the input data, operation steps, expected functional execution results, and database data change results. Next, each test case is assigned a unique number, indicating its functional module, scenario type, and priority (e.g., core functional test cases are set to high priority). Finally, all test cases are integrated into a test case set.

[0172] Step S73: Run the test case set, monitor the function execution results, response time and resource consumption of the software version after code update, and verify the integrity, consistency and accuracy of the data in the database version after data update;

[0173] It should be noted that "function execution result" refers to checking whether the software outputs the expected result (such as interface prompts or page redirects) after executing the test case operation, thus determining whether the function is implemented normally; "monitoring response time" refers to recording the time elapsed from operation execution to result output, thus determining whether it meets performance requirements (e.g., response time ≤ 1 second); "monitoring resource usage" refers to recording the server's CPU utilization, memory usage, disk I / O, as well as database query time and connection count, thus determining whether the software's resource consumption during runtime is reasonable. "Verifying data integrity" refers to checking whether all the data that should be generated after function execution exists in the database; "verifying data consistency" refers to checking whether there are any conflicts between related data tables; and "verifying data accuracy" refers to checking whether the data values ​​are consistent with expectations.

[0174] In addition, test cases should be executed according to priority: high-priority core function test cases should be executed first to ensure that key functions are verified first; if a high-priority test case fails, the execution of low-priority test cases can be paused to fix the core problem and improve testing efficiency; at the same time, the running status of the test environment should be recorded. If an environmental anomaly occurs during the test (such as server crash or database connection failure), the test cases should be re-executed after eliminating environmental factors to avoid misjudgment.

[0175] Specifically, in the test environment built in step S71, the updated software version and the updated database version are deployed to ensure a normal connection between the software and the database, and the automated testing tools are configured. High-priority test cases are then retrieved from the test case set and executed one by one using automated tools or manual operation. During execution, the execution results, response time, and server and database resource usage are monitored in real time. After each test case is executed, a data validation SQL is immediately executed to check the integrity, consistency, and accuracy of the data. Next, test process data is recorded: the execution result (pass / fail), response time, resource usage data, and data validation result of each test case are associated and stored with the test case number to form a test execution detail. Finally, the test case set is run: after all test cases have been executed, all monitoring data and validation results are summarized.

[0176] Step S74: Record the test error information during the test process, and generate a test report based on the test error information. The test report is used to determine whether the joint debugging test is passed. The test error information includes the error location, error type, and error triggering conditions.

[0177] It should be noted that test error messages refer to exceptions that occur during test case execution that do not match the expected results. Error location refers to the specific location where the exception occurred, including code location, UI location, and database location; error type refers to the category of exception, including functional error, performance error, compatibility error, and data error; error triggering conditions refer to the specific operations and input data that caused the exception to occur. A test report is a formal document that integrates test case execution results, error messages, and environment information, and must include four core parts: test overview, test results, error details, and test conclusions.

[0178] Specifically, the test cases that failed are selected from the test execution details. The anomalies corresponding to each test case are extracted, and the error location (code, interface, database), error type (functionality, performance, data, etc.), and error triggering conditions (operation steps + input data) are clearly identified. Each error message is numbered and associated with the corresponding test case number and test environment information. The compiled error information is then entered into the defect management tool, supplemented with error screenshots, log files, data verification results, and other attachments, and the severity of the defect is marked (e.g., a core function error is a serious defect, an interface display error is a minor defect). Next, a test report is written, first introducing the test overview (test environment, test scope, number of test cases); then presenting the test results (test case pass rate, list of passed / failed test cases); then listing the detailed error details (defect number, location, type, triggering conditions, severity); finally, giving the test conclusion (pass / fail) based on preset pass criteria. Finally, the test report is sent to the relevant personnel and archived in the version control repository, completing all operations in this step.

[0179] This embodiment ensures that the test environment and production environment are configured completely identically, thus avoiding the problem of "tests passing but production failing" due to environmental differences. It restores the real operating scenario, reduces production risks, and verifies version quality from multiple dimensions to ensure stability. It also comprehensively verifies the synergistic effect of code and data, avoiding quality vulnerabilities caused by single-dimensional testing.

[0180] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0181] This application also provides a version update device, please refer to... Figure 3 The version update device includes:

[0182] The acquisition module 31 is used to acquire the update version information of the software to be updated, intercept the original structured query language SQL, and generate the syntax tree corresponding to the original SQL. The update version information includes the update SQL and the update code block.

[0183] The generation module 32 is used to generate the target SQL by updating the fields of the syntax tree according to the SQL to be updated;

[0184] The determination module 33 is used to determine the code location of the original code block based on the code task identifier of the code block to be updated, and generate the target code;

[0185] The update module 34 is used to perform version updates and tests on the software to be updated based on the target SQL and the target code, and complete the version update task.

[0186] The version update apparatus provided in this application, employing the version update method in the above embodiments, can solve the technical problems in the background art. Compared with the prior art, the beneficial effects of the version update apparatus provided in this application are the same as those of the version update method provided in the above embodiments, and other technical features in the version update apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0187] This application provides a version update device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the version update method in Embodiment 1 above.

[0188] The following is for reference. Figure 4 The diagram illustrates a structural schematic suitable for implementing the version update device in the embodiments of this application. The version update device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 4 The illustrated version update device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0189] like Figure 4As shown, the version update device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in the read-only memory 1002 or a program loaded from the storage device 1003 into the random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the version update device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the version update device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows version update devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0190] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0191] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology 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.

[0192] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the version update methods provided by the methods described above.

[0193] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0194] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0195] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A version update method, characterized in that, include: The process involves obtaining the version information of the software to be updated, including receiving a version update request instruction for the software to be updated. This instruction includes the version update target, the scope of functional changes, and data adjustment requirements. Based on the version update target, the process retrieves the basic version information of the software to be updated from the version management repository. This basic version information includes the basic codebase and the basic database table structure. The process also involves filtering out code blocks to be updated based on the scope of functional changes and associating them with unique code task identifiers. Furthermore, it involves generating SQL statements to be updated based on the data adjustment requirements. Finally, the process integrates the code blocks to be updated with the SQL statements to form the version information to be updated. Finally, it intercepts the original Structured Query Language (SQL) statements and generates a syntax tree corresponding to the original SQL statements. The version information to be updated includes both the SQL statements to be updated and the code blocks to be updated. Based on the SQL to be updated, the syntax tree is updated with fields and then transformed to generate the target SQL; Based on the code task identifier of the code block to be updated, the code location of the original code block is determined, and target code is generated. A code task association table for the software to be updated is established, which records the storage path, module affiliation, and dependencies of the code task identifier and the original code block. The code task identifier of the code block to be updated is matched with the code task association table to determine the code location of the original code block. The code logic framework of the original code block is extracted, and the functional code fragments in the code block to be updated are embedded into the code logic framework to form preliminary target code. Dependency checks and syntax corrections are performed on the preliminary target code, and it is determined whether the preliminary target code is compatible with the existing code system of the software to be updated, thus generating the final target code. Based on the target SQL and the target code, the software to be updated is updated and tested to complete the version update task.

2. The version update method as described in claim 1, characterized in that, The interception of the original Structured Query Language (SQL) and the generation of the syntax tree corresponding to the original SQL include: Deploy an SQL interceptor adapted to the data interaction framework of the software to be updated, and capture the original SQL during the execution of the software to be updated through the SQL interceptor; The original SQL is parsed using a syntax analysis tool to identify its statement type. Based on the statement type of the original SQL, a syntax tree is constructed that is consistent with the syntax structure of the original SQL. The syntax tree contains a list of fields, a list of values, and logical relationship nodes of the original SQL.

3. The version update method as described in claim 1, characterized in that, The step of updating the syntax tree based on the SQL to be updated and then transforming it to generate the target SQL includes: Parse the SQL to be updated and extract the target fields contained in the SQL to be updated. The target fields include the change version number field, the operation type field, and the release status field. Based on the statement type corresponding to the original SQL, locate the relevant nodes in the syntax tree related to the target field, insert the target field into the relevant nodes in the syntax tree, and simultaneously supplement the value information corresponding to the target field; Perform syntax validation on the updated syntax tree. Once the validation passes, convert the syntax tree back into executable target SQL.

4. The version update method as described in claim 1, characterized in that, The process of updating and testing the software to be updated based on the target SQL and the target code to complete the version update task includes: The target code is deployed to the code module corresponding to the software to be updated, replacing the original code block to form a software version with updated code; The target SQL is executed in the test database of the software to be updated to complete the database table structure adjustment and data update, forming the updated database version. The software version after code updates and the database version after data updates are subjected to joint debugging tests, which include functional testing, performance testing and compatibility testing. If the test fails, adjust the target code and target SQL according to the test error message, and re-execute the integration test until the test passes; If the test passes, the target code and the target SQL will be synchronously deployed to the production environment of the software to be updated, thus completing the version update task.

5. The version update method as described in claim 4, characterized in that, The joint debugging test between the updated software version and the updated database version includes: Construct a test environment consistent with the production environment of the software to be updated, the test environment including servers, databases and dependent components with the same configuration; For the scope of functional changes to the software to be updated, a test case set is designed, which includes normal scenario test cases, abnormal scenario test cases, and boundary scenario test cases. Run the test case set to monitor the function execution results, response time, and resource consumption of the software version after the code update, and verify the integrity, consistency, and accuracy of the data in the database version after the data update; Record test error information during the testing process and generate a test report based on the test error information. The test report is used to determine whether the joint debugging test is passed. The test error information includes the error location, error type and error triggering conditions.

6. A version update device, characterized in that, include: The acquisition module is used to acquire the version information of the software to be updated. It receives a version update request instruction corresponding to the software to be updated, which includes the version update target, the scope of functional changes, and data adjustment requirements. Based on the version update target, it retrieves the basic version information of the software to be updated from the version management repository. The basic version information includes the basic code library and the basic database table structure. It filters out the code blocks to be updated according to the scope of functional changes and associates them with unique code task identifiers. It generates the SQL to be updated according to the data adjustment requirements. It integrates the code blocks to be updated and the SQL to be updated to form the version information to be updated. It intercepts the original Structured Query Language (SQL) and generates a syntax tree corresponding to the original SQL. The version information to be updated includes the SQL to be updated and the code blocks to be updated. The generation module is used to update the fields of the syntax tree based on the SQL to be updated and then transform it to generate the target SQL. The determination module is used to determine the code location of the original code block based on the code task identifier of the code block to be updated, generate target code, and establish a code task association table for the software to be updated. The code task association table records the storage path, module affiliation, and dependency relationship between the code task identifier and the original code block. The module matches the code task identifier of the code block to be updated with the code task association table to determine the code location of the original code block. The module extracts the code logic framework of the original code block, embeds the functional code fragments in the code block to be updated into the code logic framework to form preliminary target code. The module performs dependency checks and syntax correction on the preliminary target code, determines whether the preliminary target code is compatible with the existing code system of the software to be updated, and generates the target code. The update module is used to perform version updates and tests on the software to be updated based on the target SQL and the target code, and complete the version update task.

7. A version update device, characterized in that, The version update device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the version update method as described in any one of claims 1 to 5.

8. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the version update method as described in any one of claims 1 to 5.

Images