Metadatabase management method, device, electronic device and medium
Through the management method of connecting to multiple metadatabase nodes with metadatabase management end, the conflict problems caused by data sharing and interaction in software product iteration are solved, standardized management and rapid investigation of metadatabase versions are realized, and the speed of distribution and online launch is improved. .
Patent Information
- Application Number
- CN202210326771.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-03-30
- Publication Date
- 2025-02-07
- Estimated Expiration
- 2042-03-30
AI Technical Summary
During the software product iteration process, data sharing and interaction between products and product modules lead to diverse requirements for database table structure and metadata modification, resulting in mutual restraint between products, which easily lead to conflicts and is difficult to deal with.
Provide a metadatabase management method, connect to multiple metadatabase nodes through the metadatabase management end, respond to version change operations, determine the target metadatabase version, and extract the corresponding relationship between the metadatabase version and the dependent version and script information. The script applies to configuration and script storage addresses. After matching the configuration information, the script program is obtained, and the target metadatabase version is deployed on the target metadata node.
It realizes standardized management of metadata database versions, solves data conflicts between products, improves the speed of distribution and online launch, ensures the normal operation of the deployed metadata database version, and can quickly troubleshoot problems when problems occur.
Smart Images

Figure CN114816470B_ABST
Abstract
Description
Technical Field
[0001] The present application belongs to the field of computer technology, and in particular, relates to a metadata database management method, device, electronic device and medium. Background Art
[0002] With the rapid iteration of software products, data is shared and interacted between products and product modules. There are many requirements for modifying database table structures and metadata. Even products in iterations have modification requirements for the same database table at the same time, which causes mutual constraints between products, often causing conflicts and making it difficult to go online. For example, the data table structure and metadata of the same product in different system architectures and individual project environments are different, which is difficult to handle. Therefore, a version management method is urgently needed to perform standardized management, resolve these conflicts in R&D, and increase the speed of version release and online release. Summary of the invention
[0003] Some embodiments of the present application provide a metadata library management method, device, electronic device and medium to solve the above technical problems as much as possible.
[0004] Some embodiments of the present application provide a metadatabase management method, which is applied to a metadatabase management terminal, wherein the metadatabase management terminal is connected to a plurality of metadatabase nodes, and the method includes:
[0005] In response to a version change operation on at least one metabase node among the plurality of metabase nodes, determining a target metabase version corresponding to the version change operation;
[0006] Determine the target dependent metadatabase version and target script information corresponding to the target metadatabase version according to the correspondence between different metadatabase versions and dependent metadatabase versions and script information;
[0007] When the deployment record of the target dependent metadatabase version exists in the target metadatabase node, extracting the script applicable configuration and the script storage address from the target script information;
[0008] When the script applicable configuration matches the configuration information of the target metadata repository node, obtaining the script program from the script storage address;
[0009] The script program is executed to deploy the target metadatabase version on the target metadatabase node.
[0010] Optionally, the correspondence between the metadata version and the script information is constructed by the following steps:
[0011] In response to the construction instruction of the corresponding relationship, displaying a version tree including the hierarchical relationship between metadata repository versions;
[0012] In response to a new addition operation on any version parent node in the version tree, create a version child node under the version parent node, and obtain and store metadata library version information;
[0013] In response to a script entry operation on the metadata library version information, acquiring and storing script information;
[0014] The metadatabase version information and the script information are stored in association with each other.
[0015] Optionally, after displaying the version tree including the association relationship between the metadata repository versions, the method further includes:
[0016] In response to an edit operation on any target version node in the version tree, displaying version information and script information corresponding to the target version node;
[0017] In response to an editing operation on the version information and / or the script information, the version information and / or the script information indicated by the editing operation is updated.
[0018] Optionally, determining a target metadata repository version corresponding to the version change operation includes:
[0019] When there is at least one intermediate metadatabase version between the metadatabase version indicated by the version change operation and the current metadatabase version of the target metadatabase node, the intermediate metadatabase version and the metadatabase version indicated by the version change operation are used as the target metadatabase version.
[0020] Optionally, the taking the intermediate metadatabase version and the metadatabase version indicated by the version change operation as the target metadatabase version includes:
[0021] When there is at least one intermediate metadatabase version between the metadatabase version indicated by the version change operation and the current metadatabase version of the target metadatabase node, taking the intermediate metadatabase version and the metadatabase version indicated by the version change operation as the metadatabase version to be updated;
[0022] The to-be-updated metadatabase version with the lowest database version level is used as the target metadatabase version;
[0023] After executing the script program and deploying the target metadatabase version on the target metadatabase node, the method further includes:
[0024] The target metadatabase version is removed from the metadatabase versions to be updated, and the step of using the metadatabase version to be updated with the lowest level as the target metadatabase version is re-entered until the metadatabase version to be updated does not exist, and the version update process for the target metadatabase node is terminated.
[0025] Optionally, after taking the to-be-updated metadatabase version with the lowest database version level as the target metadatabase version, the method further comprises:
[0026] When the target metadatabase version update fails, the updated content of the target metadatabase version is rolled back, and the version update process for the target metadatabase node is terminated.
[0027] Optionally, the node information of the metadata database node is edited by the following steps:
[0028] In response to an instruction to edit the metadata node information, displaying a metadatabase node tree including a hierarchical relationship between metadatabase nodes;
[0029] In response to an edit operation on any target metabase node identifier in the metabase node tree, displaying metabase node information corresponding to the target metabase node identifier;
[0030] In response to an editing operation on the metadatabase node information, the metadatabase node information is updated.
[0031] Some embodiments of the present application provide a metadatabase management device, which is applied to a metadatabase management terminal, wherein the metadatabase management terminal is connected to a plurality of metadatabase nodes, and the device includes:
[0032] An input module, configured to, in response to a version change operation on at least one of the plurality of metadatabase nodes, determine a target metadatabase version corresponding to the version change operation;
[0033] A verification module, used to determine the target dependent metadatabase version and target script information corresponding to the target metadatabase version according to the correspondence between different metadatabase versions and dependent metadatabase versions and script information;
[0034] When the deployment record of the target dependent metadatabase version exists in the target metadatabase node, extracting the script applicable configuration and the script storage address from the target script information;
[0035] When the script applicable configuration matches the configuration information of the target metadata repository node, obtaining the script program from the script storage address;
[0036] The deployment module is used to execute the script program and deploy the target metadatabase version on the target metadatabase node.
[0037] Optionally, the device further comprises: an editing module, configured to:
[0038] In response to the construction instruction of the corresponding relationship, displaying a version tree including the hierarchical relationship between metadata repository versions;
[0039] In response to a new addition operation on any version parent node in the version tree, create a version child node under the version parent node, and obtain and store metadata library version information;
[0040] In response to a script entry operation on the metadata library version information, acquiring and storing script information;
[0041] The metadatabase version information and the script information are stored in association with each other.
[0042] Optionally, the editing module is further used to:
[0043] In response to an edit operation on any target version node in the version tree, displaying version information and script information corresponding to the target version node;
[0044] In response to an editing operation on the version information and / or the script information, the version information and / or the script information indicated by the editing operation is updated.
[0045] Optionally, the verification module is further configured to use the intermediate metadatabase version and the metadatabase version indicated by the version change operation as the target metadatabase version when there is at least one intermediate metadatabase version between the metadatabase version indicated by the version change operation and the current metadatabase version of the target metadatabase node.
[0046] Optionally, the verification module is further used to:
[0047] When there is at least one intermediate metadatabase version between the metadatabase version indicated by the version change operation and the current metadatabase version of the target metadatabase node, taking the intermediate metadatabase version and the metadatabase version indicated by the version change operation as the metadatabase version to be updated;
[0048] The to-be-updated metadatabase version with the lowest database version level is used as the target metadatabase version;
[0049] The target metadatabase version is removed from the metadatabase versions to be updated, and the step of using the metadatabase version to be updated with the lowest level as the target metadatabase version is re-entered until the metadatabase version to be updated does not exist, and the version update process for the target metadatabase node is terminated.
[0050] Optionally, the deployment module is further used to:
[0051] When the target metadatabase version update fails, the updated content of the target metadatabase version is rolled back, and the version update process for the target metadatabase node is terminated.
[0052] Optionally, the editing module is further used to:
[0053] In response to an instruction to edit the metadata node information, displaying a metadatabase node tree including a hierarchical relationship between metadatabase nodes;
[0054] In response to an edit operation on any target metabase node identifier in the metabase node tree, displaying metabase node information corresponding to the target metabase node identifier;
[0055] In response to an editing operation on the metadatabase node information, the metadatabase node information is updated.
[0056] Some embodiments of the present application provide a computing processing device, including:
[0057] a memory having computer readable code stored therein;
[0058] One or more processors. When the computer readable code is executed by the one or more processors, the computing processing device executes the metadata database management method as described above.
[0059] Some embodiments of the present application provide a computer program, including a computer-readable code, which, when executed on a computing and processing device, causes the computing and processing device to execute the metadata library management method as described above.
[0060] Some embodiments of the present application provide a computer-readable medium, in which the metadata database management method as described above is stored.
[0061] The present application provides a metadatabase management method, device, electronic device and medium, which centralize the metadata version update process to the metadatabase management end for unified management. Therefore, when the metadatabase node connected to the metadatabase management end performs data update, it is first confirmed that the metadatabase node has a dependent metadatabase version corresponding to the target metadatabase version to be updated, ensuring that the deployed version can be supported by the dependent metadatabase version, and then after confirming that the configuration information of the metadatabase node matches the script applicable configuration of the target metadatabase node, the script program is executed to deploy the target metadatabase version, ensuring that the metadatabase version can run normally after deployment, and when problems occur, they can be quickly checked through version deployment records at the metadata management end.
[0062] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS
[0063] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0064] Figure 1 A schematic diagram of a process flow of a metadata database management method provided by some embodiments of the present application is schematically shown;
[0065] Figure 2 The schematic diagram schematically shows a principle diagram of a metadata database management method provided by some embodiments of the present application;
[0066] Figure 3 One of the flowcharts of another metadata database management method provided by some embodiments of the present application is schematically shown;
[0067] Figure 4 The second flowchart schematically shows another metadata database management method provided in some embodiments of the present application;
[0068] Figure 5 The third flowchart schematically shows another metadata database management method provided in some embodiments of the present application;
[0069] Figure 6The schematic diagram schematically shows another principle diagram of a metadata database management method provided by some embodiments of the present application;
[0070] Figure 7 A fourth flowchart schematically illustrates another metadata database management method provided in some embodiments of the present application;
[0071] Figure 8 The structure diagram of a metadata database management device provided in some embodiments of the present application is schematically shown;
[0072] Fig. 9 A block diagram schematically shows a computing and processing device for executing the method according to some embodiments of the present application;
[0073] Fig.10 A storage unit for holding or carrying program codes for implementing methods according to some embodiments of the present application is schematically shown. DETAILED DESCRIPTION
[0074] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, 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 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.
[0075] Figure 1 A metadatabase management method provided by the present application is schematically shown, which is applied to a metadatabase management terminal, wherein the metadatabase management terminal is connected to a plurality of metadatabase nodes, and the method comprises:
[0076] It should be noted that metadata refers to structured data (such as title, version, publication data, related instructions, including retrieval points, etc.) extracted from information resources to describe their characteristics and content, and is used to organize, describe, retrieve, save, and manage information and knowledge resources. For example, our company's various servers, terminals, industries, projects, cooperative hospitals, platforms, platform users, permissions, roles, log types, administrative divisions, business alarm types and other information, then the metadata database node is a database node used to store metadata, and the metadata database node can be a distributed database, so there can be multiple metadata database nodes. The metadata database management end is a server or personal computer, tablet computer, portable mobile terminal device with data processing, data transmission, data storage and other functions, etc., which is used to manage the data and database version updates of the connected metadata database nodes. The metadata database server can communicate with multiple metadata database nodes through a visual network or the Internet. When different metabase nodes are connected to the metabase management terminal, they need to register and enter their own information, at least the dependent metabase version, script information and version deployment record. The dependent metabase version is the metadata version that the metabase node needs to reference or rely on to run, the script information is the script program required for the deployment of different metadata versions, and the version deployment record refers to the historical record of the metabase version deployed by the metabase script.
[0077] Step 101: In response to a version change operation on at least one metabase node among the plurality of metabase nodes, determine a target metabase version corresponding to the version change operation.
[0078] In the embodiment of the present application, when the user needs to change the version of a target metadatabase node, the user can perform a version change operation on the metadatabase management terminal. Based on the version change operation, the metadatabase management terminal determines the target metadatabase node indicated by the version change operation from the multiple metadatabase nodes connected, and determines the target metadatabase version indicated by the version change operation from the multiple metadatabase versions. It can be understood that the embodiment of the present application centralizes the previous update process for different metadatabase versions on the metadatabase management terminal for unified management, so as to facilitate the management of version updates of different metadatabase nodes.
[0079] Step 102: Determine the target dependent metadatabase version and target script information corresponding to the target metadatabase version according to the correspondence between different metadatabase versions and dependent metadatabase versions and script information.
[0080] In the embodiment of the present application, since different metadatabase versions depend on different metadatabase versions, if a target metadatabase version needs to be deployed on a target metadatabase node, it is necessary to know whether the metadatabase version that the target metadatabase version depends on has been deployed on the target metadatabase node. Therefore, the deployment record of the dependent metadatabase version of the target metadatabase version can be queried in the version deployment record. After each successful deployment of a metadatabase version, the metadatabase node will update the deployment record of the metadatabase version in its corresponding version deployment record.
[0081] Step 103: When the deployment record of the target dependent metadatabase version exists in the target metadatabase node, extract the script applicable configuration and the script storage address from the target script information.
[0082] In an embodiment of the present application, if the dependent metadatabase version of the target metadatabase version has not been deployed on the target metadatabase node, the deployment process of the target metadatabase version on the target metadatabase node is stopped; if the dependent metadatabase version of the target metadatabase version has been deployed on the target metadatabase node, the deployment process of the target metadatabase version is continued, i.e., the script applicable configuration and the script storage address are extracted from the script information of the target metadatabase version. The script applicable configuration refers to the hardware conditions required to run the script, such as device model, content size, bandwidth size, and the software conditions such as the driver and system architecture required for the script to run, and the permission conditions such as the logged-in user and password on the metadatabase node, which can be set according to actual needs and are not limited here. The script storage address refers to the physical address where the script program code is stored.
[0083] Step 104: when the script applicable configuration matches the configuration information of the target metadata repository node, obtain the script program from the script storage address.
[0084] In an embodiment of the present application, the metadatabase management end obtains the configuration information of the target metadatabase node from the target metadatabase node or reads the pre-stored configuration information from the database of the present application, and compares the configuration information with the applicable configuration of the script. If the configuration information of the target metadatabase node is completely consistent with the applicable configuration of the script, the script program can be further read from the script storage address for subsequent target metadatabase version deployment.
[0085] Specifically, refer to Figure 2, when upgrading, select the version number to be upgraded, and then check whether the dependent version of this version has been deployed. If the dependent version does not exist, the upgrade will not be performed; if it does exist, all SQL (Structured Query Language) scripts in this version are executed one by one. Before executing each SQL script, check whether the applicable architecture of the script matches the architecture of the node, and compare whether the applicable environment of the script matches the environment information of the node. If they match, parse the SQL script and execute each SQL statement in the script. If one condition does not match, the script is ignored and not executed. All SQLs of a version are submitted as a transaction. If an error occurs during the execution of a SQL statement in this version, all SQLs are rolled back; if all SQL statements in this version are executed successfully, a version record is inserted into the version table in the database, indicating that the node has been upgraded to this version.
[0086] Step 105: execute the script program to deploy the target metadatabase version on the target metadatabase node.
[0087] In the embodiment of the present application, the metabase management terminal executes all script programs of the target metadata version one by one. Before executing each script program, it detects whether the applicable architecture of the script matches the architecture of the target metabase node, and compares whether the applicable configuration information of the script is configured with the configuration information of the target metabase node. If they match, the script program continues to be parsed and executed. If a condition is not configured during the script program running, the script program can be stopped or ignored and the next script program can be directly executed. All script programs of a target metabase version are submitted as a transaction. If an error occurs during the execution of a script program in the target metabase version, all script programs are rolled back. If all script programs in the target metabase version are executed successfully, the version deployment record of the target metabase version is inserted into the version deployment record of the target metabase node, indicating that the target metabase node has deployed the target metadata version, that is, in the target metabase that needs to be deployed, there is a special version table for storing version deployment records. Each time a version is deployed, a version deployment record is inserted into the version table.
[0088] The embodiment of the present application centralizes the metadata version update process to the metadatabase management end for unified management. Therefore, when the metadatabase node connected to the metadatabase management end updates data, it is first confirmed that the metadatabase node has a dependent metadatabase version corresponding to the target metadatabase version to be updated, ensuring that the deployed version can be supported by the dependent metadatabase version. After confirming that the configuration information of the metadatabase node matches the script applicable configuration of the target metadatabase node, the script program is executed to deploy the target metadatabase version, ensuring that the metadatabase version can run normally after deployment, and when problems occur, they can be quickly checked through the version deployment record at the metadata management end.
[0089] Optionally, refer to Figure 3 The correspondence between the metadata version and the script information is constructed by following steps 201 to 204:
[0090] Step 201 : In response to the instruction for constructing the corresponding relationship, a version tree including the hierarchical relationship between metadata repository versions is displayed.
[0091] In the embodiment of the present application, the metadata version can be a major version or a minor version. The difference is that no script information is added to the major version, and the metadata version of the major version can be deployed through the script information of the metadata repository version of the minor version. Therefore, the superior-subordinate relationship between metadata repository versions can be represented by a version tree.
[0092] In actual applications, users can view version data by displaying nodes on the metadata management side, and then select the node where the metadata version to be updated is located on the version data to create a metadata database version. If the selected node is the root node, it means that a major version is created. If the selected node is a major version, a minor version of the metadata is created.
[0093] Step 202: In response to a new addition operation on any version parent node in the version tree, a version child node under the version parent node is created, and metadatabase version information is obtained and stored.
[0094] In an embodiment of the present application, when creating a metadatabase version, the user needs to enter the attribute information of the metadatabase version to be created on the metadatabase management end. The attribute information includes the version number, the associated product name plus the version number, the version description information, the connected developer information, the creation time, and the version number of the metadatabase version that depends on it, etc. The specific settings can be based on actual needs and are not limited here.
[0095] Step 203: In response to the script entry operation on the metadatabase version information, obtain and store script information.
[0096] In an embodiment of the present application, the metadatabase management terminal will enter the attribute information input by the user into the version library. If the metadata version created is a major version, the creation is completed and there is no need to continue to enter the script information. If the metadatabase version created is a minor version, after the version is created, script information must be added to the metadatabase version. When adding script information, it is necessary to set the attribute information of the script, including the script applicable configuration, the metadatabase identifier executed by the script, the mapping database identifier, the script storage address, etc. The script applicable configuration includes the script applicable architecture and the script applicable environment, which can be set according to actual needs and are not limited here.
[0097] Step 204: store the metadatabase version information and the script information in association with each other.
[0098] In an embodiment of the present application, after the new script information is added, the metadatabase management end will associate the script information with the newly created metadatabase version and store it in the version library, and then copy the script storage address of the script program to a directory uniformly planned according to the version number for encrypted storage. In this way, multiple scripts can be added according to actual needs.
[0099] Optionally, refer to Figure 4 After step 201, the method further includes:
[0100] Step 301: In response to an edit operation on any target version node in the version tree, display the version information and script information corresponding to the target version node.
[0101] In an embodiment of the present application, a user may edit any target version node in the script data in the display interface of the metadata repository management terminal to display the version information and script information corresponding to the version number in the property display area.
[0102] Step 302: In response to an editing operation on the version information and / or the script information, update the version information and / or the script information indicated by the editing operation.
[0103] In an embodiment of the present application, the user can modify the version information and / or script information in the display interface and then click the save function option to rewrite the latest version information into the version library.
[0104] The user can select the script to be modified in the script list interface of the display interface, and then modify the script information and script content, enter the latest property values in each property box, and after the modification is completed, click the Save option to update the latest script information to the version library.
[0105] Of course, the user can also select a script in the display interface and click the delete option to delete the script information in the version library and delete the corresponding script file in the script directory.
[0106] Step 303: In response to the viewing operation on the script information, a script program is obtained from the script storage address, and code information of the script program is displayed.
[0107] In an embodiment of the present application, when a user selects a script in the script tree of the display interface, data will be read from the basic library and the script information of that version will be displayed on the display interface, for example, applicable environment, applicable system architecture, database applicable to the script and other attribute information. When a user clicks on a script information in the script list, data will still be read from the script library and the script information will be displayed on the display interface. The user can click on the script information to read the script information from the script directory and decrypt it, and then display the decrypted script information on the display interface.
[0108] Optionally, the method further includes: in response to a metadatabase node creation operation, acquiring and storing metadatabase node information, the metadatabase node information including: at least one of a host name, a port number, maintenance personnel information, a password, a system architecture, a project environment, and a cluster node relationship.
[0109] In the embodiment of the present application, the user can click the create option in the node tree displayed on the display interface of the metadata management terminal, and then set the properties of the node to be created, including the host name, port number, maintenance personnel information, password, system architecture, project environment, cluster node relationship, etc., which can be set according to actual needs and are not limited here. The metadata library management terminal will store the property information and write it into the node library.
[0110] Optionally, refer to Figure 5 , the node information of the metadata database node is edited by following steps 401 to 403:
[0111] Step 401 , in response to an instruction to edit metadata node information, display a metadatabase node tree including a hierarchical relationship between metadatabase nodes.
[0112] Step 402: In response to an edit operation on any target metabase node identifier in the metabase node tree, display the metabase node information corresponding to the target metabase node identifier.
[0113] In the embodiment of the present application, after the display interface of the metadatabase management terminal displays the node tree, the user can use a target metadatabase node identifier on the node tree to make the display interface display the attribute information of the node.
[0114] Step 403: in response to the editing operation on the metadatabase node information, update the metadatabase node information.
[0115] In the embodiment of the present application, the user can click on the metadatabase node information of a node in the metadatabase node data in the display interface, modify some displayed attribute information and click the save option to update the latest attribute information to the node library. Of course, a metadatabase node can also be deleted, thereby deleting the metadatabase node from the node tree and the node library.
[0116] Further, see Figure 6 In addition to the operations of adding, deleting, modifying and checking the metadata database version and metadata nodes described above, the metadata database management terminal can also click a node in the interface node tree, click the historical version interface, connect to the node database, read the version record from the version table, and then display it on the interface. Click a node in the interface node tree, right-click and select the backup library option, the database backup program will be called, and the database will be backed up to the specified address. Click a node in the interface node tree, right-click and select the restore library option, the database restore program will be called, the selected restore script will be read, and the database will be restored to the historical state.
[0117] Optionally, step 101 includes: when there is at least one intermediate metadatabase version between the metadatabase version indicated by the version change operation and the current metadatabase version of the target metadatabase node, using the intermediate metadatabase version and the metadatabase version indicated by the version change operation as the target metadatabase version.
[0118] In the embodiment of the present application, if the metadatabase version indicated by the version change operation is not version-adjacent to the current metadatabase version currently deployed by the target metadatabase node, that is, there is at least one metadatabase version between the two versions that is higher in level than the current metadatabase version but lower in level than the metadatabase version indicated by the version change operation, then it is impossible to directly update from the current metadatabase version to the metadatabase version indicated by the operation. At this time, it can be determined that the metadatabase version indicated by the version change operation and the intermediate metadatabase version are both target metadatabase versions, and the target metadatabase node is updated in sequence according to the version hierarchy order relationship between the multiple target metadatabase versions.
[0119] Optionally, refer to Figure 7 A flowchart showing another method for managing a metadata database provided by an embodiment of the present application is shown below:
[0120] Step 501: In response to a version change operation on at least one metabase node among the plurality of metabase nodes, when there is at least one intermediate metabase version between the metabase version indicated by the version change operation and the current metabase version of the target metabase node, the intermediate metabase version and the metabase version indicated by the version change operation are used as metabase versions to be updated.
[0121] In the embodiment of the present application, there is usually a dependency relationship between metadatabase versions at different levels, so it is necessary to first deploy a metadatabase version at a lower level on the target metadatabase node before continuing to deploy a metadatabase version at a higher level.
[0122] Specifically, during the actual updating process, the metadatabase version indicated by the version changing operation and the intermediate metadatabase version are firstly used as the metadatabase version to be updated for subsequent version updating one by one.
[0123] Step 502: The to-be-updated metadatabase version with the lowest database version level is used as the target metadatabase version.
[0124] In the embodiment of the present application, since the low-level metadatabase version may be the dependent metadatabase version of the high-level metadatabase version, the present application uses the lowest version level among the metadatabase versions to be updated as the target metadatabase version of this version update. It should be noted that the level of the metadatabase version here does not refer to the order of release time of the metadatabase versions, but the dependency relationship between the metadatabase versions. The lower the level of the metadatabase version with the lower dependency relationship, the lower the level of the metadatabase version. On the contrary, the higher the level of the metadatabase version with the higher dependency relationship, the higher the level of the metadatabase version. For example, there are metadatabase version 1, metadatabase version 2, and metadatabase version 3 with later distribution time. Metabase version 1 is the dependent metadatabase version of metadatabase version 2, but metadatabase version 3 is the latest version of the dependent metadatabase version of metadatabase version 1. Therefore, metadatabase version 3 is also the dependent source database version of metadatabase version 1. The version levels are arranged from low to high in the following order: metadatabase version 3, metadatabase version 1, and metadatabase version 2. Of course, this is just an exemplary description. The specific hierarchical relationship can be set according to actual needs and is not limited here.
[0125] Step 503: Determine the target dependent metadatabase version and target script information corresponding to the target metadatabase version according to the correspondence between different metadatabase versions and dependent metadatabase versions and script information.
[0126] This step can refer to the detailed description of step 102 and will not be repeated here.
[0127] Step 504: When the deployment record of the target dependent metadatabase version exists in the target metadatabase node, the script applicable configuration and the script storage address are extracted from the target script information.
[0128] This step can refer to the detailed description of step 103 and will not be repeated here.
[0129] Step 505: when the script applicable configuration matches the configuration information of the target metadata repository node, obtain the script program from the script storage address.
[0130] This step can refer to the detailed description of step 104 and will not be described again here.
[0131] Step 506: execute the script program to deploy the target metadatabase version on the target metadatabase node.
[0132] This step can refer to the detailed description of step 105 and will not be repeated here.
[0133] Step 507, remove the target metadatabase version from the metadatabase versions to be updated, and re-enter the step of using the metadatabase version to be updated with the lowest level as the target metadatabase version, until the metadatabase version to be updated does not exist, and then terminate the version update process for the target metadatabase node.
[0134] In an embodiment of the present application, after the target database version is updated successfully, the lowest level metadatabase version is selected from the remaining metadatabase versions to be updated as the next target metadatabase version for metadatabase update, so that the metadatabase versions are updated in sequence from low to high according to the version hierarchy relationship until the metadatabase version indicated by the version update operation is updated.
[0135] Step 508: When the target metadatabase version update fails, roll back the updated content of the target metadatabase version, and terminate the version update process for the target metadatabase node.
[0136] In the application embodiment, if during the update process the deployment record of the target dependent metadatabase version does not exist in the target metadatabase node, or if the script applicable configuration does not match the configuration information of the target metadatabase node, then it is determined that the target metadatabase version update has failed. At this time, all previous updates to the target metadatabase version are rolled back and restored to the initial metadatabase version of the target metadatabase before the version update, that is, the current metadatabase version in the above description.
[0137] In the process of updating the metadata database across versions, the embodiment of the present application updates the metadata database in order from low to high according to the version hierarchy relationship between the metadata database versions to be updated, ensuring that there is no dependency on the metadata database version during the metadata cross-version update process, thereby improving the stability of the metadata version.
[0138] Figure 8 The schematic diagram of the structure of a metadata library management device 60 provided by the present application is schematically shown, which is applied to a metadata library management terminal, and the metadata library management terminal is connected to multiple metadata library nodes. The device includes:
[0139] An input module 601 is configured to, in response to a version change operation on at least one of the plurality of metadatabase nodes, determine a target metadatabase version corresponding to the version change operation;
[0140] Verification module 602, used to determine the target dependent metadatabase version and target script information corresponding to the target metadatabase version according to the correspondence between different metadatabase versions and dependent metadatabase versions and script information;
[0141] When the deployment record of the target dependent metadatabase version exists in the target metadatabase node, extracting the script applicable configuration and the script storage address from the target script information;
[0142] When the script applicable configuration matches the configuration information of the target metadata repository node, obtaining the script program from the script storage address;
[0143] The deployment module 603 is used to execute the script program and deploy the target metadatabase version on the target metadatabase node.
[0144] Optionally, the device further comprises: an editing module, configured to:
[0145] In response to the construction instruction of the corresponding relationship, displaying a version tree including the hierarchical relationship between metadata repository versions;
[0146] In response to a new addition operation on any version parent node in the version tree, create a version child node under the version parent node, and obtain and store metadata library version information;
[0147] In response to a script entry operation on the metadata library version information, acquiring and storing script information;
[0148] The metadatabase version information and the script information are stored in association with each other.
[0149] Optionally, the editing module is further used to:
[0150] In response to an edit operation on any target version node in the version tree, displaying version information and script information corresponding to the target version node;
[0151] In response to an editing operation on the version information and / or the script information, the version information and / or the script information indicated by the editing operation is updated.
[0152] Optionally, the verification module 602 is further configured to use the intermediate metadatabase version and the metadatabase version indicated by the version change operation as the target metadatabase version when there is at least one intermediate metadatabase version between the metadatabase version indicated by the version change operation and the current metadatabase version of the target metadatabase node.
[0153] Optionally, the verification module 602 is further used to:
[0154] When there is at least one intermediate metadatabase version between the metadatabase version indicated by the version change operation and the current metadatabase version of the target metadatabase node, taking the intermediate metadatabase version and the metadatabase version indicated by the version change operation as the metadatabase version to be updated;
[0155] The to-be-updated metadatabase version with the lowest database version level is used as the target metadatabase version;
[0156] The target metadatabase version is removed from the metadatabase versions to be updated, and the step of using the metadatabase version to be updated with the lowest level as the target metadatabase version is re-entered until the metadatabase version to be updated does not exist, and the version update process for the target metadatabase node is terminated.
[0157] Optionally, the deployment module 603 is further used to:
[0158] When the target metadatabase version update fails, the updated content of the target metadatabase version is rolled back, and the version update process for the target metadatabase node is terminated.
[0159] Optionally, the editing module is further used to:
[0160] In response to an instruction to edit the metadata node information, displaying a metadatabase node tree including a hierarchical relationship between metadatabase nodes;
[0161] In response to an edit operation on any target metabase node identifier in the metabase node tree, displaying metabase node information corresponding to the target metabase node identifier;
[0162] In response to an editing operation on the metadatabase node information, the metadatabase node information is updated.
[0163] The embodiment of the present application centralizes the metadata version update process to the metadatabase management end for unified management. Therefore, when the metadatabase node connected to the metadatabase management end updates data, it is first confirmed that the metadatabase node has a dependent metadatabase version corresponding to the target metadatabase version to be updated, ensuring that the deployed version can be supported by the dependent metadatabase version. After confirming that the configuration information of the metadatabase node matches the script applicable configuration of the target metadatabase node, the script program is executed to deploy the target metadatabase version, ensuring that the metadatabase version can run normally after deployment, and when problems occur, they can be quickly checked through the version deployment record at the metadata management end.
[0164] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.
[0165] The various component embodiments of the present application can be implemented in hardware, or in software modules running on one or more processors, or in a combination thereof. It should be understood by those skilled in the art that a microprocessor or digital signal processor (DSP) can be used in practice to implement some or all functions of some or all components in the computing processing device according to the embodiment of the present application. The application can also be implemented as a device or apparatus program (e.g., computer program and computer program product) for executing part or all of the methods described herein. Such a program implementing the present application can be stored on a computer-readable medium, or can have the form of one or more signals. Such a signal can be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.
[0166] For example, Fig. 9A computing processing device that can implement the method according to the present application is shown. The computing processing device traditionally includes a processor 710 and a computer program product or computer-readable medium in the form of a memory 720. The memory 720 can be an electronic memory such as a flash memory, an EEPROM (electrically erasable programmable read-only memory), an EPROM, a hard disk or a ROM. The memory 720 has a storage space 730 for a program code 731 for executing any method step in the above method. For example, the storage space 730 for the program code may include individual program codes 731 for implementing various steps in the above method respectively. These program codes can be read from or written to one or more computer program products. These computer program products include program code carriers such as a hard disk, a compact disk (CD), a memory card or a floppy disk. Such a computer program product is usually as described in reference Fig.10 The portable or fixed storage unit. The storage unit may have Fig. 9 The memory 720 in the computing and processing device of the computer 731 is similarly arranged as a storage segment, a storage space, etc. The program code can be compressed, for example, in an appropriate form. Typically, the storage unit includes a computer readable code 731', that is, a code that can be read by a processor such as 710, which, when executed by the computing and processing device, causes the computing and processing device to perform the various steps in the method described above.
[0167] It should be understood that, although the steps in the flowchart of the accompanying drawings are displayed in sequence as indicated by the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least a part of the steps in the flowchart of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a part of the sub-steps or stages of other steps.
[0168] The term "one embodiment", "embodiment" or "one or more embodiments" herein means that a particular feature, structure or characteristic described in conjunction with the embodiment is included in at least one embodiment of the present application. In addition, please note that the examples of the term "in one embodiment" here do not necessarily all refer to the same embodiment.
[0169] In the description provided herein, a large number of specific details are described. However, it is understood that the embodiments of the present application can be practiced without these specific details. In some instances, well-known methods, structures and techniques are not shown in detail so as not to obscure the understanding of this description.
[0170] In the claims, any reference signs placed between brackets shall not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The present application may be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third etc. does not indicate any order. These words may be interpreted as names.
[0171] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. 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 method for managing a metadata database, characterized in that: Applied to a metadatabase management terminal, the metadatabase management terminal is connected to a plurality of metadatabase nodes, and the method comprises: In response to a version change operation on at least one metabase node among the plurality of metabase nodes, determining a target metabase node indicated by the version change operation and a target metabase version corresponding to the version change operation; Determine the target dependent metadatabase version and target script information corresponding to the target metadatabase version according to the correspondence between different metadatabase versions and dependent metadatabase versions and script information; When the deployment record of the target dependent metadatabase version exists in the target metadatabase node, extracting the script applicable configuration and the script storage address from the target script information; When the script applicable configuration matches the configuration information of the target metadata repository node, obtaining the script program from the script storage address; Executing the script program to deploy the target metadatabase version on the target metadatabase node; The correspondence between the metadata library version and the script information is constructed by the following steps: In response to the construction instruction of the corresponding relationship, displaying a version tree including the hierarchical relationship between metadata repository versions; In response to a new addition operation on any version parent node in the version tree, create a version child node under the version parent node, and obtain and store metadata library version information; In response to a script entry operation on the metadata database version information, obtaining and storing script information, wherein the script information is a script program required for deployment of different metadata versions; The metadatabase version information and the script information are stored in association with each other.
2. The method according to claim 1, characterized in that After displaying the version tree including the association relationship between the metadata repository versions, the method further includes: In response to an edit operation on any target version node in the version tree, displaying version information and script information corresponding to the target version node; In response to an editing operation on the version information and / or the script information, the version information and / or the script information indicated by the editing operation is updated.
3. The method according to claim 1, characterized in that The determining of the target metadata repository version corresponding to the version change operation includes: When there is at least one intermediate metadatabase version between the metadatabase version indicated by the version change operation and the current metadatabase version of the target metadatabase node, the intermediate metadatabase version and the metadatabase version indicated by the version change operation are used as the target metadatabase version.
4. The method according to claim 3, characterized in that The step of using the intermediate metadatabase version and the metadatabase version indicated by the version change operation as the target metadatabase version includes: When there is at least one intermediate metadatabase version between the metadatabase version indicated by the version change operation and the current metadatabase version of the target metadatabase node, taking the intermediate metadatabase version and the metadatabase version indicated by the version change operation as the metadatabase version to be updated; The to-be-updated metadatabase version with the lowest database version level is used as the target metadatabase version; After executing the script program and deploying the target metadatabase version on the target metadatabase node, the method further includes: The target metadatabase version is removed from the metadatabase versions to be updated, and the step of using the metadatabase version to be updated with the lowest database version level as the target metadatabase version is re-entered until the metadatabase version to be updated does not exist, and the version update process for the target metadatabase node is terminated.
5. The method according to claim 4, characterized in that After taking the to-be-updated metadatabase version with the lowest database version level as the target metadatabase version, the method further includes: When the target metadatabase version update fails, the updated content of the target metadatabase version is rolled back, and the version update process for the target metadatabase node is terminated.
6. The method according to claim 1, characterized in that The node information of the metadata database node is edited by the following steps: In response to an instruction to edit the metadata node information, displaying a metadatabase node tree including a hierarchical relationship between metadatabase nodes; In response to an edit operation on any target metabase node identifier in the metabase node tree, displaying metabase node information corresponding to the target metabase node identifier; In response to an editing operation on the metadatabase node information, the metadatabase node information is updated.
7. A metadata database management device, characterized in that: Applied to a metadatabase management terminal, the metadatabase management terminal is connected to a plurality of metadatabase nodes, and the device comprises: An input module, configured to, in response to a version change operation on at least one metabase node among the plurality of metabase nodes, determine a target metabase node indicated by the version change operation and a target metabase version corresponding to the version change operation; A verification module, used to determine the target dependent metadatabase version and target script information corresponding to the target metadatabase version according to the correspondence between different metadatabase versions and dependent metadatabase versions and script information; When the deployment record of the target dependent metadatabase version exists in the target metadatabase node, extracting the script applicable configuration and the script storage address from the target script information; When the script applicable configuration matches the configuration information of the target metadata repository node, obtaining the script program from the script storage address; A deployment module, used for executing the script program and deploying the target metadatabase version on the target metadatabase node; The device further comprises: an editing module, configured to: In response to the construction instruction of the corresponding relationship, displaying a version tree including the hierarchical relationship between metadata repository versions; In response to a new addition operation on any version parent node in the version tree, create a version child node under the version parent node, and obtain and store metadata library version information; In response to a script entry operation on the metadata database version information, obtaining and storing script information, wherein the script information is a script program required for deployment of different metadata versions; The metadatabase version information and the script information are stored in association with each other.
8. A computing device, characterized in that: include: a memory having computer readable code stored therein; One or more processors, when the computer readable code is executed by the one or more processors, the computing processing device performs the metadata database management method according to any one of claims 1 to 6.
9. A computer-readable medium, characterized in that The metadata database management method according to any one of claims 1 to 6 is stored therein.
Citation Information
Patent Citations
Method and device for controlling version change of database
CN111708764A