A data update method and device based on hash algorithm

Abstract

This application provides a data update method and apparatus based on a hash algorithm. The method acquires information about the database to be updated and creates a corresponding database instance. Based on a preset algorithm and a pre-defined structured query language, it determines the first hash value set of each first metadata file in the database instance to be updated. Based on version update information from the user terminal, it determines the updated code version data. It then identifies the second metadata file of the updated code version data to determine the second hash value set of the second metadata file. Based on the matching result between the first and second hash value sets, it determines the metadata file to be updated in each of the first metadata files. Based on the metadata file to be updated, a preset update sequence list, and the second metadata file, it updates the corresponding metadata file to be updated sequentially. This solves the problems of low update efficiency and wasted manpower in querying update error logs in current engineering projects.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a data update method and device based on a hash algorithm. Background Technology

[0002] With the development of internet technology, internet engineering projects are becoming increasingly common. As clients' demands for project usage grow, modifications or the addition of new features to specific areas are inevitable.

[0003] As the project's codebase and scale increase, updating the database information takes longer and longer. Furthermore, many uncontrollable factors arise during the update process, making update failures common. This forces developers to constantly monitor update progress and all update logs, resulting in low update efficiency. When an update error occurs, it's necessary to query all update logs, wasting manpower. Summary of the Invention

[0004] This application provides a data update method and device based on a hash algorithm to solve the problems of low update efficiency in current engineering projects, where updating errors require querying logs of all updated content, wasting manpower.

[0005] On one hand, embodiments of this application provide a data update method based on a hash algorithm, the method comprising:

[0006] Obtain the database information to be updated and create the corresponding database instance to be updated;

[0007] Based on a preset algorithm and a pre-set structured query language, the first hash value set of each first metadata file in the database instance to be updated is determined;

[0008] Based on version update information from the user terminal, the updated code version data is determined; and the second metadata file of the updated code version data is identified to determine the second hash value set of the second metadata file.

[0009] Based on the matching results between the first hash value set and the second hash value set, determine the metadata files to be updated in each of the first metadata files;

[0010] Based on the metadata file to be updated, the preset update sequence list, and the second metadata file, the corresponding metadata files to be updated are updated sequentially.

[0011] In one implementation of this application, the first hash value of each of the first metadata files is calculated using the preset algorithm; and

[0012] Determine the correspondence between each of the first metadata files and the code version data to be updated; wherein, the correspondence includes the association between the code module corresponding to the code version data to be updated and each of the first metadata files;

[0013] Based on each first hash value and the corresponding relationship with the first hash value, a set of first hash values ​​matching the number of code modules is generated; the set of first hash values ​​is a set of first hash values ​​arranged in a predetermined order; the predetermined order matches the sorting of the metadata files of each code module.

[0014] In one implementation of this application, a preset code management tool is used to obtain version update information from the user terminal and update the current code version number and the current code; the version update information includes the updated code and the code version number;

[0015] Once the version update information has been updated, a restart command is generated, and the current service process is restarted according to the restart command, so that the updated code version data can be determined in the restarted service process.

[0016] In one implementation of this application, each updated code module corresponding to the updated code version data is determined;

[0017] The system crawls each of the updated code modules using a preset format crawling command, and determines the corresponding second metadata file for each of the updated code modules based on the crawled code data; wherein, the format crawling command is used to crawl code with a format extension of a preset metadata format; the preset metadata format includes at least: script file format and configuration file format;

[0018] Based on each of the second metadata files, a plurality of sets of the second hash values ​​matching the number of each of the updated code modules are generated using the preset algorithm.

[0019] In one implementation of this application, each of the first hash value sets is stored in a hash table of the database to be updated;

[0020] Based on the matching results between the first hash value set and the second hash value set, the metadata files to be updated in each of the first metadata files are determined, specifically including:

[0021] Obtain the set of each of the first hash values ​​in the hash table of the database to be updated;

[0022] And determine the code module corresponding to each of the first hash value sets;

[0023] Determine the update code module corresponding to each of the second hash value sets;

[0024] Match whether the code module and the updated code module are the same project module;

[0025] If so, compare the hash values ​​in the first hash value set corresponding to the same project module with the hash values ​​in the second hash value set;

[0026] If the comparison results are inconsistent, the first metadata file corresponding to the inconsistent hash value is used as the metadata file to be updated; the metadata file to be updated includes an empty metadata file.

[0027] In one implementation of this application, based on the metadata file to be updated and the preset dependency relationship, a first metadata file that the metadata file to be updated depends on is determined as a dependent metadata file, and the dependent metadata file is added to the metadata file to be updated, so as to update the corresponding metadata file to be updated in sequence according to the metadata file to be updated, the update sequence list and the second metadata file; the dependency relationship is that there is a base class inheritance relationship between the metadata files.

[0028] In one implementation of this application, the update sequence list includes the update order of the metadata files to be updated; the update order is to update the metadata files in script file format first, and then update the metadata files in configuration file format.

[0029] In one implementation of this application, based on the user's selection operation of each of the metadata files to be updated through the user terminal, the selected metadata file to be updated and its corresponding dependent metadata file are used as the metadata file to be updated.

[0030] The metadata file to be updated is updated according to the second metadata file and the update sequence list.

[0031] In one implementation of this application, when updating the corresponding metadata files to be updated, the update result of each metadata file to be updated is determined;

[0032] If the update result is unsuccessful, an error log is generated; and it is determined whether there is a preset dependency relationship between the next metadata file to be updated and the metadata file to be updated that malfunctioned; wherein, the next metadata file to be updated and the metadata file to be updated that malfunctioned have the same metadata format;

[0033] If not, update the next metadata file to be updated.

[0034] On the other hand, embodiments of this application also provide a data update device based on a hash algorithm, the device comprising:

[0035] At least one processor; and,

[0036] A memory communicatively connected to the at least one processor; wherein,

[0037] The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0038] Obtain the database information to be updated and create the corresponding database instance to be updated;

[0039] Based on a preset algorithm and a pre-set structured query language, the first hash value set of each first metadata file in the database instance to be updated is determined;

[0040] Based on version update information from the user terminal, the updated code version data is determined; and the second metadata file of the updated code version data is identified to determine the second hash value set of the second metadata file.

[0041] Based on the matching results between the first hash value set and the second hash value set, determine the metadata files to be updated in each of the first metadata files;

[0042] Based on the metadata file to be updated, the preset update sequence list, and the second metadata file, the corresponding metadata files to be updated are updated sequentially.

[0043] The above technical solution utilizes the hash values ​​of the metadata files in the database to be updated and the hash values ​​of the metadata files corresponding to the updated project's code to determine the metadata files that need updating. These metadata files are then selectively updated. This allows for a clear view of the differences between the code and database metadata information; the entire metadata file loading and upgrade process is transparent and controllable with a small impact; and it eliminates the need to update all files in the entire module, enabling differential data updates and significantly improving database update efficiency. This solves the current problems of low update efficiency in engineering projects, where errors require querying logs of the entire update content, wasting manpower.

[0044] Meanwhile, this application can load and update the corresponding metadata for changed files and record the file update log, which not only improves the efficiency of metadata loading, but also avoids problems such as uncontrollable data caused by loading the entire module or project. Attached Figure Description

[0045] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0046] Figure 1 This is a flowchart illustrating a data update method based on a hash algorithm in an embodiment of this application.

[0047] Figure 2 This is a schematic diagram of another data update method based on a hash algorithm in the embodiments of this application;

[0048] Figure 3 This is a schematic diagram of the structure of a data update device based on a hash algorithm in an embodiment of this application. Detailed Implementation

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

[0050] This application provides a data update method and device based on a hash algorithm to solve the problems of low update efficiency in current engineering projects, where updating errors require querying logs of all updated content, wasting manpower.

[0051] During the software development or customer implementation phase of an engineering project, it's inevitable to need to fix bugs or add new features, and to update the database via upgrade operations, including updating the model and field descriptions in the script file (.py file) and the pre-defined data descriptions in the configuration file (.xml file).

[0052] This process involves handling dependencies between various modules. If the module that needs updating happens to be one of the bottom five layers and has many dependencies, then all dependent modules will be included in the upgrade process.

[0053] The loading and upgrading of line metadata takes longer and longer as the project grows larger, and there are many uncertainties in the upgrading process.

[0054] The metadata referred to in this application mainly includes model description information, field description information, and pre-built data.

[0055] The information includes description files for models and fields in script file format (.py files), and description files for pre-defined data in configuration file format (.xml files). This is achieved by calculating and comparing metadata descriptions corresponding to different code versions.

[0056] The hash value of the file accurately identifies the files with changed metadata descriptions between two versions. The corresponding metadata is loaded and updated for the changed files, and the file update log is recorded. This not only improves the efficiency of metadata loading, but also avoids problems such as uncontrollable data caused by loading the entire module or project.

[0057] 5. The various embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0058] This application provides a data update method based on a hash algorithm, such as... Figure 1 As shown, the

[0059] The method may include steps S101-S105:

[0060] S101, the server obtains the database information to be updated and creates the corresponding database instance to be updated.

[0061] It should be noted that the server, as the executor of the data update method based on the hash algorithm, is only an example of 0. The executor is not limited to the server, and this application does not make any specific limitation in this regard.

[0062] The database to be updated is the one the server connects to; the server is the execution platform for the project performing code version updates. The server can first retrieve the database information from the database to be updated and then create a database instance for that database. The database instance is the channel through which users access the database.

[0063] All operations performed on the data within the database instance, including data definition, data querying, data maintenance, and database operation control, are conducted within the database instance. Applications can only interact with the data through the database instance.

[0064] Dealing with the warehouse.

[0065] S102, the server determines the first hash value set of each first metadata file in the database instance to be updated based on a preset algorithm and a pre-set structured query language.

[0066] After the server creates the database instance to be updated, it will use a preset algorithm and a pre-defined structured query language to determine the first hash value set of each first metadata file in the instance.

[0067] The preset algorithm can be Secure Hash Algorithm 1 (SHA-1), and the preset Structured Query Language (SQL) statement can be used to query the first metadata file stored in the database to be updated. The first metadata file includes .py files and .xml files. The server calculates the hash value of each first metadata file using SHA-1.

[0068] Specifically, the server calculates the first hash value of each first metadata file using the preset algorithm SHA-1, and determines the correspondence between each first metadata file and the code version data to be updated. This correspondence includes the association between the code module corresponding to the code version data to be updated and each first metadata file.

[0069] The first metadata file corresponds to the code in the associated code version data to be updated. Since metadata is data that describes data, that is, data that describes the relationship between codes, a first metadata file can correspond to a part of the code. This correspondence is pre-stored in the database by the server.

[0070] Then, the server generates a set of first hash values ​​that matches the number of code modules, based on each first hash value and its corresponding relationship. This set of first hash values ​​is a collection of first hash values ​​arranged in a predetermined order. This predetermined order matches the sorting of the metadata files for each code module.

[0071] A code module is a module defined when the code is written. Each code module may correspond to several metadata files. Based on the code contained in each code module, the metadata file corresponding to the code is determined. The first hash value is then determined based on the corresponding metadata file, thus revealing the correspondence between the code and the first hash value. Furthermore, the first hash values ​​contained in each code module can be determined, thereby generating a first hash value set. The elements in the first hash value set are arranged in an ordered manner, which can be done according to the sorting of the metadata files.

[0072] In this embodiment of the application, after the server determines the first hash value set of each first metadata file in the database instance to be updated, the server can store each first hash value set in the hash table of the database to be updated; wherein, the hash table is a hash table.

[0073] S103, the server determines the updated code version data based on the version update information from the user terminal. It then identifies the second metadata file of the updated code version data to determine the second hash value set of the second metadata file.

[0074] The user terminal can be a terminal corresponding to a specific developer, and this terminal can be a server, computer, or other device; this application does not impose specific limitations on this. Version update information includes updated code and code version number.

[0075] Specifically, based on version update information from user terminals, the updated code version data is determined, including:

[0076] The server obtains version update information from the user's terminal through a pre-set code management tool (such as the open-source distributed version control system Git), and updates the current code version number and the current code.

[0077] Git allows servers to update the current version of code on the server using code versions from user terminals.

[0078] Once the version update information is updated, a restart command is generated, and the current service process is restarted according to the restart command so that the updated code version data can be determined in the restarted service process.

[0079] In other words, once the server has updated its code version, the service can be restarted.

[0080] Furthermore, the server identifies the second metadata file of the updated code version data to determine the second set of hash values ​​for the second metadata file, specifically including:

[0081] The server can identify the updated code modules corresponding to the updated code version data. It then crawls each updated code module using preset format crawling instructions to determine the corresponding second metadata files for each module based on the crawled code data. The format crawling instructions are used to crawl code with extensions in the preset metadata format. The preset metadata formats include at least script file formats and configuration file formats. Based on each second metadata file, a preset algorithm generates multiple sets of second hash values ​​matching the number of each updated code module.

[0082] In other words, the server can first use the format crawling command to crawl the metadata file corresponding to the updated code, calculate the second hash value in the manner described in step S102 above, and divide the second hash value set according to the updated code module.

[0083] For example, before an update, the server had four software modules A, B, C, and D, containing 50, 60, 80, and 100 primary metadata files respectively. During an update, 5 new metadata files were added to module B, and 10 existing metadata files were modified, resulting in changes to 15 primary metadata files in module B. The hash values ​​of these 65 metadata files in module B form a secondary hash value set.

[0084] S104, the server determines the metadata file to be updated in each of the first metadata files based on the matching results of the first hash value set and the second hash value set.

[0085] Based on the matching results between the first hash value set and the second hash value set, the server determines the metadata files to be updated in each of the first metadata files, specifically including:

[0086] First, the server retrieves the first hash value set from the hash table of the database to be updated, and then determines the code module corresponding to each first hash value set.

[0087] Because the database was not updated after the code was updated, the server can still obtain the first set of hash values ​​from the database. The code modules are software modules A, B, C, and D as illustrated in the example above.

[0088] Then, the server determines the update code module corresponding to each set of second hash values.

[0089] Update code modules such as software modules A, B, C, and D.

[0090] The server can match whether the code module and the updated code module are from the same project module.

[0091] That is, software modules A, B, C, and D in the code module are matched and updated respectively with software modules A, B, C, and D in the code module, with A matching A, B matching B, and so on.

[0092] When the server matching code module and the update code module are the same project module, compare the hash values ​​in the first hash value set and the second hash value set corresponding to the same project module.

[0093] In other words, the server can compare the first hash value of the metadata file of the same project module with the second hash value of the metadata file corresponding to the same project module. For example, the first hash value of the metadata file 'a' in module A is x1, and the second hash value is x2.

[0094] If the comparison results are inconsistent, the first metadata file corresponding to the inconsistent hash value will be used as the metadata file to be updated. The metadata file to be updated includes empty metadata files.

[0095] In the example above, if x1 is not equal to x2, the comparison result is inconsistent, and the first metadata file a is the metadata file to be updated.

[0096] Furthermore, if the second metadata file is a newly added metadata file and there is no corresponding first metadata file, the server can generate an empty metadata file as the first metadata file to update the empty metadata file based on the second metadata file.

[0097] For example, a code module includes three first metadata files: a, b, and c. The corresponding update code module includes four second metadata files: a, b, c, and d. Here, a is the metadata file to be updated due to a mismatch, and d is a newly added metadata file. In this case, the server can use an empty metadata file o as the metadata file corresponding to d in the code module. Thus, the first metadata files include a, b, c, and o. If the hash value of the empty metadata file is preset to 0, then the hash value of d will also be inconsistent with the hash value of the empty metadata file, and the first metadata file o will also be the metadata file to be updated.

[0098] S105, the server updates the corresponding metadata file to be updated sequentially based on the metadata file to be updated, the preset update sequence list, and the second metadata file.

[0099] In this embodiment of the application, based on the metadata file to be updated, the preset update sequence list, and the second metadata file, the corresponding metadata file to be updated is updated sequentially, specifically including:

[0100] The server can determine the first metadata file that the metadata file to be updated depends on, based on the metadata file to be updated and the preset dependencies. This dependent metadata file is then added to the metadata file to be updated. The server then updates the corresponding metadata file sequentially based on the metadata file to be updated, the update sequence list, and the second metadata file. The dependency relationship is a base class inheritance relationship between the metadata files.

[0101] In other words, if code modules A, B, C, and D contain 50, 60, 80, and 100 metadata description files respectively, and this update adds 5 new metadata files and modifies 10 existing ones, after the code update, by detecting changes in the hash values ​​of the metadata files, it's possible to accurately locate these 15 changed metadata files. Furthermore, based on the dependencies between models, it's possible to determine the files in modules C and D that depend on these 15 metadata files. Therefore, during the update, the relevant files can be updated accurately based on this dependency relationship, and other unrelated files do not need to be loaded or updated. The dependency relationship is a model inheritance relationship; metadata may have inheritance relationships, such as a base class q and its subclass models.

[0102] Since the metadata of the pre-built data is updated before the metadata of the model and fields is updated, the corresponding model and field metadata will not be able to be matched when the model and field metadata are updated subsequently. Therefore, the pre-built data, i.e. the .xml format metadata file, needs to be updated after the .py metadata file.

[0103] Therefore, the update sequence list mentioned above includes the update order of the metadata files to be updated. The update order is to update the metadata files in script file format first, and then update the metadata files in configuration file format.

[0104] In this embodiment of the application, based on the metadata file to be updated, the preset update sequence list, and the second metadata file, the corresponding metadata file to be updated is updated sequentially, specifically including:

[0105] Based on the user's selection of metadata files to be updated via the user terminal, the server designates the selected metadata files and their corresponding dependent metadata files as the metadata files to be updated. Then, based on the second metadata file and according to the update sequence list, the metadata files to be updated are updated.

[0106] In other words, after receiving the metadata file to be updated, the server can send the title information of that metadata file to the user terminal, where the user terminal can then display the file. After the user selects the metadata file to be updated on their terminal, the server performs the update operation based on the selected file and its corresponding dependent metadata files.

[0107] In one embodiment of this application, since the update of the metadata file may fail, the server can also perform the following scheme. Specifically, as follows.

[0108] When updating the corresponding metadata files to be updated, the server determines the update result of each file. If the update fails, an error log is generated. It then determines whether there is a pre-defined dependency between the next metadata file to be updated and the file that reported the error. The next metadata file to be updated and the file that reported the error must share the same metadata format. If it is determined that there is no pre-defined dependency between the next metadata file to be updated and the file that reported the error, the next metadata file to be updated is then updated.

[0109] Based on the above scheme, the server will first update the metadata file in script file format, and then update the metadata file in configuration file format. During the separate updates, the server can determine whether the metadata file that failed to update has any dependencies on other metadata files that need to be updated. If dependencies exist, other metadata files cannot be updated, and an alarm message will be generated and sent to the user terminal for the user to resolve the error. If no dependencies exist, other metadata files can be updated, and an alarm message will also be sent to the user terminal. Error logs will also be recorded in the database for users to view the metadata files that failed to update.

[0110] The execution flow diagram of the data update method based on the hash algorithm in this application is shown below. Figure 2 As shown, it specifically includes:

[0111] S201, Preparation; S202, Database initialization; S203, Metadata file hash calculation initialization; S204, Update project code and restart service; S205, Recalculate file hash (i.e., the hash value of the updated second metadata file); S206, Determine if the description file (comparing hash values) has changed; S207, If yes, load the .py description file to handle model inheritance; S208, Load the .xml description file; S209, Generate log records; S2010, Update the database file hash record table (i.e., record the hash value of the updated metadata file in the hash table); S2011, If ​​no, no change log records; S2012, Terminate.

[0112] Application examples of this application include: (i) Developers first initialize a database instance based on the customer's code version. This process automatically initializes the metadata description file hash values ​​of all modules and stores them in the data table.

[0113] (ii) Developers develop features and update the code to the local development environment. Then, they restart the service, and the system will automatically calculate the hash value of the description file for the new code version.

[0114] (III) The metadata description files modified in this update will be displayed through the system interface. Developers can directly select the description files that need to be loaded and upgraded, including .py and .xml files, to update the differential metadata.

[0115] (iv) After the update is completed, the new features will take effect at runtime, the changed description file hash value will be successfully updated to the database hash table, and the entire update process will end.

[0116] During the development or implementation of a project, if it is necessary to adjust the database table structure or update the default data in the database table, it is necessary to load and update the metadata description file. Since the specific changes included in the update are unknown after updating the project code, the entire project must be updated and upgraded to overwrite the metadata that needs to be updated. This is not only inefficient, but the entire process of loading metadata is also a black box. Developers cannot control which specific metadata description files are updated, resulting in a wide range of impacts and many uncontrollable factors. The above technical solution can effectively avoid the above problems.

[0117] This application enables: after updating the code, the differences between the code and the database metadata information can be seen intuitively; the entire upgrade process of loading metadata files is transparent and controllable, with a small impact; and it does not require updating all files of the entire module, greatly improving efficiency.

[0118] The above technical solution allows for a clearer identification of the metadata files involved in the update, eliminating the need to update all metadata files; only the relevant differential metadata files need to be updated. This solves the problems of low update efficiency in current engineering projects, where errors require querying logs of all update content, resulting in wasted manpower.

[0119] Figure 3 A data update device based on a hash algorithm is provided in this application embodiment. The device includes:

[0120] At least one processor; and a memory communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0121] The system acquires the database information to be updated and creates the corresponding database instance. Based on a preset algorithm and a pre-defined structured query language, it determines the first hash value set of each first metadata file in the database instance to be updated. Based on version update information from the user terminal, it determines the updated code version data. It then identifies the second metadata file of the updated code version data to determine the second hash value set of the second metadata file. Based on the matching results of the first and second hash value sets, it determines the metadata file to be updated in each of the first metadata files. Based on the metadata file to be updated, the preset update sequence list, and the second metadata file, it updates the corresponding metadata file to be updated sequentially.

[0122] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0123] The devices and methods provided in this application are one-to-one correspondences. Therefore, the devices also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices will not be repeated here.

[0124] It should also be noted that the terms "including," "comprising," or any other variations thereof are intended to cover non-

[0125] Exclusive inclusion means that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising a…" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0126] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A data update method based on a hash algorithm, characterized in that, The method includes: Obtain the database information to be updated and create the corresponding database instance to be updated; Based on a preset algorithm and a pre-set structured query language, the first hash value set of each first metadata file in the database instance to be updated is determined; Based on version update information from the user terminal, the updated code version data is determined; and the second metadata file of the updated code version data is identified to determine the second hash value set of the second metadata file. Based on the matching results between the first hash value set and the second hash value set, determine the metadata files to be updated in each of the first metadata files; Based on the metadata file to be updated, the preset update sequence list, and the second metadata file, the corresponding metadata files to be updated are updated sequentially; wherein, the update sequence list includes the update order of the metadata files to be updated; the update order is to update the metadata file in script file format first, and then update the metadata file in configuration file format. After determining the first hash value set of each first metadata file in the database instance to be updated, the method further includes: Store each of the first hash value sets in a hash table of the database to be updated; Based on the matching results between the first hash value set and the second hash value set, the metadata files to be updated in each of the first metadata files are determined, specifically including: Obtain the set of each of the first hash values ​​in the hash table of the database to be updated; And determine the code module corresponding to each of the first hash value sets; Determine the update code module corresponding to each of the second hash value sets; Match whether the code module and the updated code module are the same project module; If so, compare the hash values ​​in the first hash value set corresponding to the same project module with the hash values ​​in the second hash value set; If the comparison results are inconsistent, the first metadata file corresponding to the inconsistent hash value is used as the metadata file to be updated; the metadata file to be updated includes an empty metadata file; wherein, when the second metadata file is a newly added metadata file, there is no corresponding first metadata file, and an empty metadata file is generated as the first metadata file, so as to update the empty metadata file according to the second metadata file.

2. The method according to claim 1, characterized in that, Based on a preset algorithm and a pre-defined structured query language, the set of first hash values ​​for each first metadata file in the database instance to be updated is determined, specifically including: The first hash value of each of the first metadata files is calculated using the preset algorithm; and Determine the correspondence between each of the first metadata files and the code version data to be updated; wherein, the correspondence includes the association between the code module corresponding to the code version data to be updated and each of the first metadata files; Based on each first hash value and the corresponding relationship with the first hash value, a set of first hash values ​​matching the number of code modules is generated; the set of first hash values ​​is a set of first hash values ​​arranged in a predetermined order; the predetermined order matches the sorting of the metadata files of each code module.

3. The method according to claim 1, characterized in that, Based on version update information from the user terminal, the updated code version data is determined, specifically including: The system uses a pre-defined code management tool to obtain version update information from the user terminal and updates the current code version number and the current code. The version update information includes the updated code and the code version number. Once the version update information has been updated, a restart command is generated, and the current service process is restarted according to the restart command, so that the updated code version data can be determined in the restarted service process.

4. The method according to claim 3, characterized in that, Identifying the second metadata file of the updated code version data, and determining the second hash value set of the second metadata file, specifically includes: Determine the corresponding updated code modules for the updated code version data; The system crawls each of the updated code modules using a preset format crawling command, and determines the corresponding second metadata file for each of the updated code modules based on the crawled code data; wherein, the format crawling command is used to crawl code with a format extension of a preset metadata format; the preset metadata format includes at least: script file format and configuration file format; Based on each of the second metadata files, a plurality of sets of the second hash values ​​matching the number of each of the updated code modules are generated using the preset algorithm.

5. The method according to claim 1, characterized in that, Based on the metadata file to be updated, the preset update sequence list, and the second metadata file, the corresponding metadata files to be updated are updated sequentially, specifically including: Based on the metadata file to be updated and the preset dependency relationship, the first metadata file that the metadata file to be updated depends on is determined as the dependent metadata file, and the dependent metadata file is added to the metadata file to be updated, so as to update the corresponding metadata file to be updated in sequence according to the metadata file to be updated, the update sequence list and the second metadata file; the dependency relationship is that there is a base class inheritance relationship between the metadata files.

6. The method according to claim 1, characterized in that, Based on the metadata file to be updated, the preset update sequence list, and the second metadata file, the corresponding metadata files to be updated are updated sequentially, specifically including: Based on the user's selection operation of each of the metadata files to be updated through the user terminal, the selected metadata files to be updated and their corresponding dependent metadata files are used as metadata files to be updated. The metadata file to be updated is updated according to the second metadata file and the update sequence list.

7. The method according to claim 1, characterized in that, The method further includes: In the case of updating the corresponding metadata files to be updated, determine the update results of each metadata file to be updated; If the update result is unsuccessful, an error log is generated; and it is determined whether there is a preset dependency relationship between the next metadata file to be updated and the metadata file to be updated that malfunctioned; wherein, the next metadata file to be updated and the metadata file to be updated that malfunctioned have the same metadata format; If not, update the next metadata file to be updated.

8. A data update device based on a hash algorithm, characterized in that, The device includes: at least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform a data update method based on a hash algorithm as described in any one of claims 1-7.

Images