A code upgrade method, device, equipment and medium based on hierarchical model

Abstract

The present application discloses a code upgrade method, apparatus, device and medium based on a hierarchical model, which respectively aggregates the current layer chain model, the transition layer model and the target layer chain model, and parses the structured difference analysis between the current layer chain model and the target layer chain model, including the attribute difference analysis, the structure difference analysis and the code block difference analysis of the entity nodes, thereby ensuring the model compatibility and data compatibility of the layer chain model after the upgrade, without relying on manually written update logs, and automatically performing database fitting and code upgrades, thereby improving the success rate and execution efficiency of the upgrade, and solving the technical problems of the difference between logs and actual operations, uncertainty in compatibility and low upgrade efficiency in the existing solutions.

Description

Technical Field

[0001] The present application relates to the technical field of software upgrade, and in particular to a code upgrade method, device, equipment and medium based on a hierarchical model. Background Art

[0002] In the process of software development and maintenance, layering and modularization are key strategies to improve software flexibility and scalability. As the software enters the operation and maintenance phase, it becomes particularly important to iterate existing functions and upgrade and transform them to adapt to business changes. In this process, it is a challenge to accurately locate and update the underlying modules to meet new requirements. However, as the modules continue to evolve, version compatibility issues become particularly prominent, requiring developers to overcome the following key issues:

[0003] Differences between logs and actual operations: While upgrade logs provide guidance, they rely on manual maintenance and may have issues with exhaustiveness and accuracy. This can lead to differences between theory and actual operations.

[0004] Uncertainty of compatibility: Depending on the log content, developers need to use personal experience and intuition to judge the compatibility between different versions. This process not only tests their professional ability, but also increases the risk of omissions and misunderstandings.

[0005] Efficiency challenge: Faced with the large span between versions, the upgrade log may be very large. It is a time-consuming and laborious task to quickly identify key change points from it, which seriously affects the efficiency of the upgrade. Summary of the invention

[0006] The present application provides a code upgrade method, device, equipment and medium based on a hierarchical model, which solves the technical problems existing in existing solutions such as the difference between logs and actual operations, uncertainty in compatibility and low upgrade efficiency.

[0007] In view of this, the first aspect of the present application provides a code upgrade method based on a hierarchical model, the method comprising:

[0008] Step S1, obtaining the project source code, and obtaining the model information of the current layer chain based on the project source code parsing, wherein the model information includes layer information, application information, plug-in information, extension information, and deployment mode of each layer;

[0009] Step S2: Determine a resource file for upgrading according to the model information, wherein the resource file is a layer chain node in a binary deployment form;

[0010] Step S3, obtaining the current layer chain model according to the project source code analysis and aggregation;

[0011] Step S4, obtaining a transition layer model by analyzing and aggregating the current layer chain model;

[0012] Step S5, obtaining a target layer chain model according to the resource file parsing and aggregation;

[0013] Step S6, performing database structure fitting according to the current layer chain model and the target layer chain model;

[0014] Step S7: According to the node information of the target layer chain model, the code reference relationship of the project source code is upgraded and adjusted.

[0015] Optionally, after step S5, the following steps are further included:

[0016] Performing attribute difference analysis, structure difference analysis and code block difference analysis on entity nodes of the transition layer model and the target layer chain model respectively to obtain analysis results;

[0017] Based on the analysis result, receiving an upgrade instruction sent by the user; if the upgrade instruction is an upgrade confirmation instruction, continuing to execute step S6;

[0018] If the upgrade instruction is an upgrade termination instruction, the upgrade is terminated.

[0019] Optionally, the performing attribute difference analysis of entity nodes of the transition layer model and the target layer chain model specifically includes:

[0020] Compare the node change information, attribute values ​​and reference relationships of the entity nodes corresponding to the transition layer model and the target layer chain model to determine the differences in node addition, deletion, renaming, name conflict, attribute value and reference errors.

[0021] Optionally, the performing structural difference analysis of entity nodes of the transition layer model and the target layer chain model specifically includes:

[0022] The field lengths and field precisions of the DataType nodes and TableField nodes in the transition layer model and the target layer chain model are compared to determine the differences in the field lengths and field precisions of the DataType nodes and the TableField nodes.

[0023] Optionally, the performing structural difference analysis of entity nodes of the transition layer model and the target layer chain model further includes:

[0024] According to the breadth-first principle, tree traversal fitting of the Form entity nodes and the Menu entity nodes in the transition layer model and the target layer chain model is performed, and the corresponding structural differences between the Form entity nodes and the Menu entity nodes after fitting are compared.

[0025] Optionally, after step S3, the following steps are further included:

[0026] Compare the structural consistency of the current layer chain model and the account set database model;

[0027] If they are consistent, then step S4 is executed; otherwise, the upgrade is terminated.

[0028] Optionally, after step S2, the following steps are further included:

[0029] The rationality of the resource file is verified, and if the verification passes, step S3 is executed, otherwise the upgrade is terminated.

[0030] A second aspect of the present application provides a code upgrade device based on a hierarchical model, the device comprising:

[0031] An acquisition unit, used to acquire project source code, and parse the project source code to obtain model information of the current layer chain, wherein the model information includes layer information, application information, plug-in information, extension information, and deployment mode of each layer;

[0032] An upgrade resource determination unit, used to determine a resource file for upgrading according to the model information, wherein the resource file is a layer chain node in a binary deployment form;

[0033] A first aggregation unit, configured to obtain a current layer chain model according to the project source code parsing and aggregation;

[0034] A second aggregation unit, which obtains a transition layer model by analyzing and aggregating the current layer chain model;

[0035] A third aggregation unit, configured to obtain a target layer chain model according to the parsing and aggregation of the resource file;

[0036] A database fitting unit, used for performing database structure fitting according to the current layer chain model and the target layer chain model;

[0037] A code upgrade unit is used to upgrade and adjust the code reference relationship of the project source code according to the node information of the target layer chain model.

[0038] A third aspect of the present application provides a code upgrade device based on a hierarchical model, the device comprising a processor and a memory:

[0039] The memory is used to store program code and transmit the program code to the processor;

[0040] The processor is used to execute the steps of the code upgrade method based on the hierarchical model as described in the first aspect according to the instructions in the program code.

[0041] A fourth aspect of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium is used to store program code, and the program code is used to execute the method described in the first aspect above.

[0042] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

[0043] In the present application, a code upgrade method, device, equipment and medium based on a layered model are provided. By respectively aggregating the current layer chain model, the transition layer model and the target layer chain model, the structured difference analysis between the current layer chain model and the target layer chain model is analyzed, including the attribute difference analysis, structure difference analysis and code block difference analysis of the entity nodes, so as to ensure the model compatibility and data compatibility of the layer chain model after the upgrade. There is no need to rely on manually written update logs, and database fitting and code upgrades are automatically performed, thereby improving the success rate and execution efficiency of the upgrade, and solving the technical problems of the difference between logs and actual operations, uncertainty in compatibility and low upgrade efficiency existing in the existing solutions. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 A method flow chart of a code upgrade method based on a hierarchical model in an embodiment of the present application;

[0045] Figure 2 This is a schematic diagram of the structure of a code upgrade device based on a hierarchical model in an embodiment of the present application;

[0046] Figure 3 This is a schematic diagram of the structure of a code upgrade device based on a hierarchical model in an embodiment of the present application. DETAILED DESCRIPTION

[0047] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0048] The present application designs a code upgrade method, device, equipment and medium based on a hierarchical model, which solves the technical problems existing in existing solutions such as the difference between logs and actual operations, uncertainty in compatibility and low upgrade efficiency.

[0049] For easier understanding, see Figure 1 , Figure 1 Flowchart of the method for upgrading the code based on the hierarchical model in the embodiment of the present application. Figure 1 As shown, specifically:

[0050] Step S1, obtaining the project source code, and obtaining the model information of the current layer chain based on the project source code analysis, the model information including layer information, application information, plug-in information, extension information and deployment mode of each layer;

[0051] It should be noted that, first, the project source code is checked out from the version control system (such as SVN). Then, the source code is parsed to obtain the detailed information of the current layer chain model, including the configuration, application, plug-in, extension and deployment mode of each layer.

[0052] For example: suppose the project has multiple vertical domain layers, including technology layer, general business layer, industry business layer, enterprise business layer, local application layer, application plug-in layer, and application extension layer. Each layer is deployed as an independent module or service. The technology layer may contain the basic database and service framework. The general business layer provides cross-industry common business logic. The industry business layer provides customized business logic for specific industries. The enterprise business layer is customized according to the specific needs of the enterprise. The local application layer is responsible for the implementation of specific functional modules. The application plug-in layer provides additional functional extensions, and the application extension layer is used for further customization and extension.

[0053] For example, the technical layer may be deployed as a set of microservices, the general business layer and industry business layer may be deployed as a set of libraries or services, and the enterprise business layer, local application layer, application plug-in layer, and application extension layer may be deployed as a set of plug-ins or extension packages.

[0054] In actual projects, the specific deployment method of each layer may vary depending on the project requirements and technology stack. It is important to ensure that each layer can be deployed and updated independently while maintaining compatibility and integration with other layers.

[0055] Step S2: Determine the resource file for upgrading according to the model information, where the resource file is a layer chain node in a binary deployment form;

[0056] It should be noted that, based on the model information parsed in step S1, the resource files that need to be upgraded are determined. These resource files should be layer chain nodes deployed in binary form.

[0057] For example, if you decide to upgrade the industry business layer, the resource file of this layer is represented by a file ending with .lyr. If you need to upgrade the application part of the general business layer, you need to find the corresponding file ending with .app. If you want to upgrade the plug-in of an application, you need to find the file ending with .app.plugin.

[0058] For example, if the project structure is as follows:

[0059] Technology layer: tech.lyr

[0060] Common business layer: commonBusiness.app

[0061] Industry Business Layer: industryBusiness.lyr

[0062] Corporate business layer: corporateBusiness.app

[0063] Local application layer: localApp.app

[0064] Application plugin layer: localApp.plugin

[0065] Application extension layer: localApp.extension

[0066] In this case, if you want to upgrade the industry business layer, you need to find the .lyr file corresponding to the industry business layer, such as industryBusiness.lyr. If you want to upgrade the application part of the common business layer, you need to find the corresponding .app file, such as commonBusiness.app. If you want to add or update a plug-in of the common business layer, you need to find the corresponding .app.plugin file.

[0067] In practice, the upgrade process may involve checking out the latest resource files from a version control system, replacing the old files in the existing deployment environment, and ensuring that the new resource files are compatible with the rest of the system.

[0068] Step S3, parse and aggregate the project source code to obtain the current layer chain model;

[0069] It should be noted that, according to the project source code parsing aggregation in step S1, a model representing the current layer chain state is constructed, and this model includes the current configuration of all layers, applications, plug-ins and extensions.

[0070] For example: Build a model that includes the current status and configuration of the technology layer, general business layer, industry business layer, enterprise business layer, local application layer, application plug-in layer, and application extension layer. For example, the technology layer may consist of multiple microservices, the general business layer may consist of a set of library files, the industry business layer may be represented by a .lyr file, the enterprise business layer and local application layer may be represented by .app files, the application plug-in layer may be represented by .app.plugin files, and the application extension layer may be represented by a set of .app.extension files.

[0071] Step S4, obtaining a transition layer model by analyzing and aggregating the current layer chain model;

[0072] It should be noted that a transition layer model is created based on the current layer chain model. This model will be used to temporarily replace the current layer chain model during the upgrade process.

[0073] For example, in the transition model, the industry business layer is replaced by a temporary .lyr file, while other layers remain unchanged. This temporary .lyr file will be used to test whether the new industry business logic is compatible with other parts of the system.

[0074] Step S5, obtaining a target layer chain model according to the resource file analysis and aggregation;

[0075] It should be noted that the target layer chain model is created based on the selected resource file. This model represents the state of the system after the upgrade.

[0076] For example, in the target model, the industry business layer is replaced by a new .lyr file, which contains all necessary updates and improvements. At the same time, if new functions are added to the local application layer, a new .app file may also be included.

[0077] Step S6, performing database structure fitting according to the current layer chain model and the target layer chain model;

[0078] It should be noted that the current layer chain model and the target layer chain model are compared and the database structure is adjusted to ensure that the database is compatible with the new target layer chain model.

[0079] For example, if the upgrade of the industry business layer introduces new database tables or fields, the database schema needs to be updated to include these new elements. This may involve adding new tables, modifying the structure of existing tables, or adding new indexes.

[0080] Step S7: According to the node information of the target layer chain model, the code reference relationship of the project source code is upgraded and adjusted.

[0081] It should be noted that the code reference relationship in the project source code is updated according to the node information of the target layer chain model to ensure that the code correctly references the newly upgraded resource files.

[0082] For example, if the .lyr file of the industry business layer is updated, then all the codes that reference this .lyr file (such as service calls in the technical layer) need to be updated to ensure that they reference the new .lyr file. Similarly, if the .app file of the local application layer is updated, then all the codes that reference this .app file (such as business logic in the enterprise business layer) also need to be updated.

[0083] By following these steps, you can ensure that the software upgrade process goes smoothly while minimizing the problems that may arise during the upgrade. Each step needs to be carefully planned and executed to ensure the integrity of the upgrade and the stability of the system.

[0084] Furthermore, after step S5, the following steps are further included:

[0085] Perform attribute difference analysis, structure difference analysis and code block difference analysis on entity nodes of transition layer model and target layer chain model respectively to obtain analysis results;

[0086] Based on the analysis result, receiving the upgrade instruction sent by the user; if the upgrade instruction is an upgrade confirmation instruction, continue to execute step S6;

[0087] If the upgrade instruction is an upgrade termination instruction, the upgrade will be terminated.

[0088] It should be noted that based on the analysis results, the system will wait for further instructions from the user. The user can send an upgrade confirmation instruction to continue the upgrade process, or send an upgrade termination instruction to stop the upgrade.

[0089] For example: After carefully reviewing the analysis results of attribute differences, structure differences, and code block differences, the user believes that the upgrade is feasible and sends an upgrade confirmation instruction.

[0090] If the user confirms the upgrade, then step S6 (database structure fitting) will be executed. If the user decides to terminate the upgrade, then the entire upgrade process will stop.

[0091] For example: After the user sends an upgrade confirmation instruction, the system will continue to execute step S6 and start upgrading the database structure to match the C model.

[0092] Furthermore, the attribute difference analysis of entity nodes of the transition layer model and the target layer chain model specifically includes:

[0093] Compare the node change information, attribute values, and reference relationships of the corresponding entity nodes of the transition layer model and the target layer chain model to determine the differences in node addition, deletion, renaming, name conflicts, attribute values, and reference errors.

[0094] It should be noted that this step involves comparing the attribute differences of entity nodes in the transition layer model (B model) and the target layer chain model (C model). The analysis includes the addition, deletion, renaming, name conflict, attribute difference, etc. of nodes.

[0095] For example: If a node in model B has an attribute called "age", and the attribute of the same node in model C is "date of birth", this difference in attributes needs to be recorded and analyzed.

[0096] Furthermore, the structural difference analysis of entity nodes between the transition layer model and the target layer chain model specifically includes:

[0097] Compare the field lengths and field precisions of the DataType nodes and TableField nodes in the transition layer model and the target layer chain model to determine the differences in the field lengths and field precisions of the DataType nodes and TableField nodes.

[0098] It should be noted that structural difference analysis refers to analyzing the structural differences between model B and model C, such as the increase or decrease of modules, changes in the relationship between layers, etc.

[0099] For example: If a payment module is added to model C but not to model B, this is a structural difference.

[0100] During the software upgrade process, it is crucial to analyze the structural differences of entity nodes between the transition layer model and the target layer chain model. This analysis focuses on the field length and field precision of DataType nodes and TableField nodes to ensure that the integrity and consistency of the data are maintained during the upgrade process.

[0101] Field length: refers to the maximum number of characters that a field can store. For example, a VARCHAR field length of 255 means that it can store up to 255 characters.

[0102] Field precision: For numeric fields, precision refers to the total number of digits in the value; for decimal fields, precision also includes the number of digits after the decimal point. For example, DECIMAL(5,2) means there are 5 digits in total, 2 of which are after the decimal point.

[0103] Compare field lengths: Checks whether the field lengths of the same fields in the transition layer model and the target layer chain model have changed. If the field length of the target model is smaller than that of the transition model, data truncation may occur.

[0104] Compare field precision: Check whether the precision of numeric fields has changed to ensure that the upgraded data can accurately reflect the original values ​​and no information is lost due to changes in precision.

[0105] Assume that in the transition layer model, there is a DataType node representing the user's date of birth, and the field type is DATE. In the target layer chain model, this field is expanded to DATETIME type to store more precise birth time. At this time, the field length does not change, but the field precision increases, and it can store richer time information.

[0106] For example, if there is a TableField node in the transition layer model that represents the amount, and the field type is DECIMAL(10,2), and in the target layer chain model, due to changes in business requirements, the type of the amount field is changed to DECIMAL(15,2). At this time, the field length is increased and can store larger amounts, but the precision remains unchanged.

[0107] Through such structural difference analysis, it can be ensured that data migration and conversion can proceed smoothly during the software upgrade process, avoiding data loss or errors caused by mismatched field length or precision.

[0108] Furthermore, the structural difference analysis of entity nodes between the transition layer model and the target layer chain model also includes:

[0109] According to the breadth-first principle, the tree traversal fitting of the Form entity nodes and Menu entity nodes in the transition layer model and the target layer chain model is performed, and the corresponding structural differences between the fitted Form entity nodes and Menu entity nodes are compared.

[0110] It should be noted that breadth-first search (BFS) is an algorithm for traversing or searching trees and graphs. It starts from the root node of the tree and traverses the nodes layer by layer until the desired node is found. In a tree structure, BFS visits each node in order from top to bottom and from left to right.

[0111] Specific steps

[0112] Initialization: Start from the root node of the Form or Menu entity node.

[0113] Queue usage: Use a queue to store the nodes to be visited.

[0114] Traversal process:

[0115] Take a node (for example, node A) from the queue.

[0116] Visit all child nodes of node A and add them to the queue.

[0117] Record the attributes and structure information of node A and its child nodes.

[0118] This process is repeated until the queue is empty.

[0119] Structural difference analysis

[0120] Node comparison: Compare the properties and structures of nodes at the same position in the transition layer model and the target layer chain model.

[0121] Attribute Difference: Records the attribute differences between nodes in two models, such as newly added attributes, deleted attributes, or changes in attribute values.

[0122] Structural changes: Identify the addition, movement, or deletion of nodes, as well as changes in parent-child relationships.

[0123] Assume that in the transition layer model, a Form entity node (node ​​A) contains two child nodes (node ​​B and node C). In the target layer chain model, the number of child nodes of node A becomes three, and node D is added.

[0124] BFS traversal:

[0125] Visit node A.

[0126] Visit nodes B and C (from the transition layer model), and visit the newly added node D (from the target layer chain model).

[0127] Record the structure and attributes of nodes B, C, and D.

[0128] Structural differences:

[0129] It is found that node D is newly added.

[0130] Comparing the attributes of nodes B and C, it is found that a certain attribute value of node B is different in the two models.

[0131] Through this method, the structural differences between the Form and Menu entity nodes in the transition layer model and the target layer chain model can be systematically identified and recorded, providing detailed data support for subsequent upgrade adjustments.

[0132] Furthermore, after step S3, the following steps are further included:

[0133] Compare the structural consistency between the current layer chain model and the account set database model;

[0134] If they are consistent, step S4 is executed, otherwise the upgrade is terminated.

[0135] It should be noted that during the software upgrade process, after step S3, a key link is to ensure the structural consistency between the current layer chain model and the account set database model. This step is crucial because any structural mismatch may cause problems during the upgrade process and may even cause data loss or system failure.

[0136] Structural consistency comparison: This step involves comparing the structure of the current layer chain model with the account set database schema to ensure compatibility between them. This includes comparing database objects such as table structure, field types, indexes, constraints (such as foreign keys), triggers, etc.

[0137] Assume that in the current layer chain model, there is a user table users, which contains the fields id (integer), name (string type), and email (string type). In the account set database mode, the users table also exists, but the name field is defined as varchar(50), while it is defined as varchar(100) in the layer chain model. This difference in field length needs to be identified and processed before upgrading.

[0138] Steps:

[0139] Use database comparison tools: You can use professional database comparison tools, such as the SQL Compare tool, to automatically compare the differences between two database structures.

[0140] Generate difference reports: These tools can generate detailed difference reports including all inconsistencies such as field type mismatches, missing indexes, different constraints, etc.

[0141] Manual review: After the automated comparison, some complex differences may need to be manually reviewed by a database administrator or developer to decide the best course of action.

[0142] Structural synchronization: Based on the comparison results, a synchronization script can be generated to apply these changes automatically or manually to make the structures of the two models consistent.

[0143] Conformity confirmation:

[0144] If the structural consistency comparison result shows that the two are completely consistent, then step S4 can be safely performed.

[0145] If inconsistencies are found, adjustments need to be made based on the difference report, which may involve modifying the database schema or updating the layer chain model. After the adjustment is completed, consistency comparison needs to be performed again until the two are completely consistent.

[0146] To terminate the upgrade:

[0147] If unresolvable structural differences are found during the structural consistency comparison process, or the required changes will result in unacceptable data loss or system risk, then the upgrade process may need to be terminated. In this case, all issues found need to be documented and solutions negotiated with the project team or a decision made whether to continue with the upgrade.

[0148] Through this meticulous comparison and review, risks during the upgrade process can be minimized, ensuring system stability and data integrity.

[0149] Furthermore, after step S2, the following steps are further included:

[0150] Verify the rationality of the resource file. If the verification passes, execute step S3; otherwise, terminate the upgrade.

[0151] It should be noted that during the software upgrade process, after step S2, a resource file rationality check is required to ensure that the selected resource file meets the upgrade requirements and will not damage the existing system. If the check passes, step S3 is continued; if the check fails, the upgrade needs to be terminated to avoid potential risks.

[0152] Resource file rationality check usually includes the following aspects:

[0153] File integrity: Checks that the file is intact and has not been damaged or incomplete during transmission. This is usually done by calculating and comparing a checksum or hash value of the file.

[0154] Version compatibility: Ensure that resource files are compatible with the existing system version to prevent system failures due to version mismatch.

[0155] Dependencies: Checks resource files for unmet dependencies or conflicts with existing system components.

[0156] Security: Scans files to ensure they do not contain malicious code or viruses.

[0157] Assuming that you are upgrading the industry business layer, after step S2, you need to perform the following verification:

[0158] Calculate the hash value of the file: For example, use the SHA-1 or SHA-256 algorithm to get a hash value and compare it with the hash value provided by the publisher to ensure that the file has not been tampered with during the download process.

[0159] Check file versions: Confirm that the new version of the library is compatible with your application's other dependencies.

[0160] Analyze dependencies: Use tools to check if the new library has new dependencies and whether these dependencies are already included in the application.

[0161] Run a security scan: Use a security tool to scan library files to ensure there are no potential security threats.

[0162] If all checks pass, it means that the resource file is reasonable and you can proceed to step S3. If any check fails, such as finding that the file is damaged or there is a security risk, the upgrade process should be terminated and the cause should be investigated.

[0163] Through such verification steps, the risks in the upgrade process can be minimized to the greatest extent and the smooth progress of the software upgrade can be ensured.

[0164] See also Figure 2 , Figure 2 Schematic diagram of the structure of the code upgrade device based on the hierarchical model in the embodiment of the present application. Figure 2 As shown, specifically:

[0165] The acquisition unit 201 is used to acquire the project source code, and obtain the model information of the current layer chain based on the project source code analysis, where the model information includes layer information, application information, plug-in information, extension information, and deployment mode of each layer;

[0166] An upgrade resource determination unit 202 is used to determine a resource file for upgrading according to the model information, where the resource file is a layer chain node in a binary deployment form;

[0167] The first aggregation unit 203 is used to parse and aggregate the project source code to obtain the current layer chain model;

[0168] The second aggregation unit 204 obtains a transition layer model by analyzing and aggregating the current layer chain model;

[0169] The third aggregation unit 205 is used to obtain a target layer chain model according to the parsing and aggregation of the resource file;

[0170] A database fitting unit 206, used for performing database structure fitting according to the current layer chain model and the target layer chain model;

[0171] The code upgrade unit 207 is used to upgrade and adjust the code reference relationship of the project source code according to the node information of the target layer chain model.

[0172] The present application embodiment also provides another code upgrade device based on a hierarchical model, such as Figure 3 As shown, the device 10 includes:

[0173] One or more processors 110 and memory 120, Figure 3 A processor 110 is used as an example for description. The processor 110 and the memory 120 may be connected via a bus or other means. Figure 3 The example of connecting through bus is taken in the following.

[0174] The processor 110 is used to complete various control logics of the device 10, and it can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), a single-chip microcomputer, an ARM (Acorn RISCMachine) or other programmable logic device, a discrete gate or transistor logic, a discrete hardware component, or any combination of these components. In addition, the processor 110 can also be any traditional processor, microprocessor or state machine. The processor 110 can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a DSP and / or any other such configuration.

[0175] The memory 120 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules, such as program instructions corresponding to the method for constructing a multilingual phoneme representation model in the embodiment of the present invention. The processor 110 executes various functional applications and data processing of the device 10 by running the non-volatile software programs, instructions and units stored in the memory 120, that is, implements the method for constructing a multilingual phoneme representation model in the above method embodiment.

[0176] The memory 120 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and applications required for at least one function; the data storage area may store data created according to the use of the device 10, etc. In addition, the memory 120 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 120 may optionally include a memory remotely arranged relative to the processor 110, and these remote memories may be connected to the device 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0177] One or more units are stored in the memory 120, and when executed by one or more processors 110, the following steps are implemented:

[0178] Step S1, obtaining the project source code, and obtaining the model information of the current layer chain based on the project source code analysis, the model information including layer information, application information, plug-in information, extension information and deployment mode of each layer;

[0179] Step S2: Determine the resource file for upgrading according to the model information, where the resource file is a layer chain node in a binary deployment form;

[0180] Step S3, parse and aggregate the project source code to obtain the current layer chain model;

[0181] Step S4, obtaining a transition layer model by analyzing and aggregating the current layer chain model;

[0182] Step S5, obtaining a target layer chain model according to the resource file analysis and aggregation;

[0183] Step S6, performing database structure fitting according to the current layer chain model and the target layer chain model;

[0184] Step S7: According to the node information of the target layer chain model, the code reference relationship of the project source code is upgraded and adjusted.

[0185] An embodiment of the present application also provides a computer-readable storage medium for storing program code, wherein the program code is used to execute any one of the implementation methods of a code upgrade method based on a hierarchical model described in the aforementioned embodiments.

[0186] In an embodiment of the present application, a code upgrade method, apparatus, device and medium based on a layered model are provided, which respectively aggregates the current layer chain model, the transition layer model and the target layer chain model, and parses the structured difference analysis of the current layer chain model and the target layer chain model, including the attribute difference analysis, the structure difference analysis and the code block difference analysis of the entity nodes, to ensure the model compatibility and data compatibility of the layer chain model after the upgrade, without relying on manually written update logs, and automatically performs database fitting and code upgrades, thereby improving the success rate and execution efficiency of the upgrade, and solving the technical problems of the difference between logs and actual operations, uncertainty in compatibility and low upgrade efficiency in the existing solutions.

[0187] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0188] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein, for example. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0189] It should be understood that in this application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0190] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0191] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0192] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0193] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (full name in English: Read-Only Memory, English abbreviation: ROM), random access memory (full name in English: Random Access Memory, English abbreviation: RAM), disk or optical disk and other media that can store program codes.

[0194] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A code upgrade method based on a hierarchical model, characterized in that: include: Step S1, obtaining the project source code, and obtaining the model information of the current layer chain based on the project source code parsing, wherein the model information includes layer information, application information, plug-in information, extension information, and deployment mode of each layer. Each layer is deployed as an independent module or service, and each layer can be independently deployed and updated while maintaining compatibility and integration with other layers; Step S2: Determine a resource file for upgrading according to the model information, wherein the resource file is a layer chain node in a binary deployment form; Step S3, obtaining a current layer chain model according to the project source code analysis and aggregation, and constructing a model representing the current layer chain state according to the project source code analysis and aggregation, wherein the current layer chain model includes the current configurations of all layers, applications, plug-ins, and extensions; Step S4: parse and aggregate the current layer chain model to obtain a transition layer model. Create a transition layer model based on the current layer chain model. The transition layer model will be used to temporarily replace the current layer chain model during the upgrade process. In the transition layer model, a specific layer is replaced by a temporary file, while other layers remain unchanged. The temporary file is used to test whether the new logic is compatible with other parts of the system. Step S5, obtaining a target layer chain model according to the resource file analysis and aggregation, and creating a target layer chain model according to the selected resource file, wherein the target layer chain model represents the state of the system after the upgrade; Step S6: fitting the database structure according to the current layer chain model and the target layer chain model, comparing the current layer chain model and the target layer chain model, and adjusting the database structure to ensure that the database is compatible with the new target layer chain model; Step S7: upgrading and adjusting the code reference relationship of the project source code according to the node information of the target layer chain model; After step S5, the following steps are also included: Performing attribute difference analysis, structure difference analysis and code block difference analysis on entity nodes of the transition layer model and the target layer chain model respectively to obtain analysis results; Based on the analysis result, receiving an upgrade instruction sent by the user; if the upgrade instruction is an upgrade confirmation instruction, continuing to execute step S6; If the upgrade instruction is an upgrade termination instruction, the upgrade is terminated.

2. The code upgrade method based on the hierarchical model according to claim 1 is characterized in that: The performing attribute difference analysis of entity nodes of the transition layer model and the target layer chain model specifically includes: Compare the node change information, attribute values ​​and reference relationships of the entity nodes corresponding to the transition layer model and the target layer chain model to determine the differences in node addition, deletion, renaming, name conflict, attribute value and reference errors.

3. The code upgrade method based on the hierarchical model according to claim 1, characterized in that: The structural difference analysis of entity nodes of the transition layer model and the target layer chain model specifically includes: The field lengths and field precisions of the DataType nodes and TableField nodes in the transition layer model and the target layer chain model are compared to determine the differences in the field lengths and field precisions of the DataType nodes and the TableField nodes.

4. The code upgrade method based on the hierarchical model according to claim 3 is characterized in that: The performing structural difference analysis of entity nodes of the transition layer model and the target layer chain model further includes: According to the breadth-first principle, tree traversal fitting of the Form entity nodes and the Menu entity nodes in the transition layer model and the target layer chain model is performed, and the corresponding structural differences between the Form entity nodes and the Menu entity nodes after fitting are compared.

5. The code upgrade method based on the hierarchical model according to claim 1, characterized in that: After step S3, the following steps are also included: Compare the structural consistency of the current layer chain model and the account set database model; If they are consistent, then step S4 is executed; otherwise, the upgrade is terminated.

6. The code upgrade method based on the hierarchical model according to claim 1, characterized in that: The step S2 further includes: The rationality of the resource file is verified, and if the verification passes, step S3 is executed, otherwise the upgrade is terminated.

7. A code upgrade device based on a hierarchical model, characterized in that: include: An acquisition unit is used to acquire project source code, and parse the project source code to obtain model information of the current layer chain, wherein the model information includes layer information, application information, plug-in information, extension information, and deployment mode of each layer. Each layer is deployed as an independent module or service, and each layer can be independently deployed and updated while maintaining compatibility and integration with other layers. An upgrade resource determination unit, used to determine a resource file for upgrading according to the model information, wherein the resource file is a layer chain node in a binary deployment form; A first aggregation unit is used to obtain a current layer chain model according to the project source code analysis and aggregation, and to build a model representing the current layer chain state according to the project source code analysis and aggregation, wherein the current layer chain model includes the current configurations of all layers, applications, plug-ins, and extensions; The second aggregation unit obtains a transition layer model by parsing and aggregating the current layer chain model, and creates a transition layer model according to the current layer chain model. The transition layer model will be used to temporarily replace the current layer chain model during the upgrade process. In the transition layer model, a specific layer is replaced by a temporary file, while other layers remain unchanged. The temporary file is used to test whether the new logic is compatible with other parts of the system; A third aggregation unit is used to obtain a target layer chain model by parsing and aggregating the resource files, and to create a target layer chain model according to the selected resource files, wherein the target layer chain model represents the state that the system should have after the upgrade; A database fitting unit, used for fitting the database structure according to the current layer chain model and the target layer chain model, comparing the current layer chain model with the target layer chain model, and adjusting the database structure to ensure that the database is compatible with the new target layer chain model; A code upgrade unit, used to upgrade and adjust the code reference relationship of the project source code according to the node information of the target layer chain model; Also includes: An analysis unit, used for performing attribute difference analysis, structure difference analysis and code block difference analysis on entity nodes of the transition layer model and the target layer chain model respectively, to obtain analysis results; The processing unit is used to receive an upgrade instruction sent by a user based on the analysis result; if the upgrade instruction is an upgrade confirmation instruction, jump to execute the database fitting unit; if the upgrade instruction is an upgrade termination instruction, terminate the upgrade.

8. A code upgrade device based on a hierarchical model, characterized in that: The device comprises a processor and a memory: The memory is used to store program code and transmit the program code to the processor; The processor is used to execute the hierarchical model-based code upgrade method described in any one of claims 1-6 according to the instructions in the program code.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium is used to store program code, and the program code is used to execute the hierarchical model-based code upgrade method according to any one of claims 1 to 6.

Images