A method, device, equipment and medium for generating incremental scripts of a database

Abstract

The present invention discloses a method, device, equipment and medium for generating incremental scripts of a database. The method generates a metamodel definition file by responding to a business form operation received from a low-code platform through a distributed version control system; when a version release instruction is received, the metamodel definition file of the released version and the model file of the field version are compared, and a model change file is generated according to the comparison result; the model change file is used to generate an incremental update script and update the field production database. Thus, by combining the distributed version control system and the editing of the low-code platform, the script update efficiency is effectively improved while maintaining the convenience of script update of the field environment database.

Description

Technical Field

[0001] The present invention relates to the field of low-code technology, and in particular to a method, device, equipment and medium for generating incremental scripts of a database. Background Art

[0002] In the traditional software development field, database development and application development often belong to different professional teams. The database development team focuses on building database structure and writing complex database logic, while the application development team focuses on developing user-oriented application functions. The two work together to realize a complete software system. When the database structure needs to be changed, it is usually dependent on a dedicated script administrator. The administrator is responsible for carefully writing and managing database DDL (Data Definition Languages) script change records. These records are extremely critical in the implementation and deployment phase of the software project. They are the basis for ensuring that the database structure of the target environment is accurately updated, thereby ensuring the stable operation of the entire software system in different environments.

[0003] However, low-code technology has significantly simplified the database development process. Its innovation lies in allowing business personnel to complete database modeling directly through interface form design operations. Based on their deep understanding of business processes and data requirements, business personnel can quickly build a preliminary database framework, which to a certain extent reduces the communication costs and development cycles caused by professional barriers in the traditional development model.

[0004] However, due to the differences between the development environment and the customer's on-site environment, in order to ensure that the database can be correctly deployed at the customer's site and consistent with the development environment, it is necessary to compare the development environment database with the on-site database. However, existing solutions usually still require manual comparison and script writing, resulting in low script update efficiency for the on-site environment database. Summary of the invention

[0005] The present invention provides a method, device, equipment and medium for generating incremental scripts of a database, which solves the technical problem that in the existing solutions, manual comparison and script writing are usually still required when updating scripts in a field database, resulting in low script updating efficiency in the field environment database.

[0006] A method for generating an incremental script of a database provided in a first aspect of the present invention is applied to a distributed version control system, wherein the distributed version control system is communicatively connected to a low-code platform, and the method comprises:

[0007] In response to a business form operation received from the low-code platform, generate a metamodel definition file;

[0008] When a version release instruction is received, the metamodel definition file and the field model file are compared, and a model change file is generated according to the comparison result;

[0009] The model change file is used to generate an incremental update script and update the on-site production database.

[0010] Optionally, the response to the business form operation received from the low-code platform generates a metamodel definition file, including:

[0011] In response to a business form operation received from the low-code platform, create a business form on the low-code platform;

[0012] Parse the business form and extract the corresponding form structure and field information;

[0013] Creating an initial model file matching the form structure according to a preset model file format;

[0014] The field information is loaded into the initial model file to generate a metamodel definition file.

[0015] Optionally, the distributed version control system is also connected to a development environment database, and the method further includes:

[0016] Parsing the metamodel definition file to generate corresponding DDL statements;

[0017] The DDL statements are loaded and executed to update the database table structure in the development environment database.

[0018] Optionally, the method further comprises:

[0019] In response to the form change operation received from the low-code platform, the metamodel definition file is updated to obtain a new metamodel definition file.

[0020] Optionally, when receiving the version release instruction, comparing the metamodel definition file and the field model file, and generating a model change file according to the comparison result, includes:

[0021] When a version release instruction is received, the metamodel definition file and the field model file are parsed respectively to obtain a definition data structure and a field data structure;

[0022] Create and associate tree nodes according to the defined data structure to generate a first memory form object tree;

[0023] Create and associate tree nodes according to the field data structure to generate a second memory form object tree;

[0024] Recursively traverse the first memory form object tree and the second memory form object tree to determine a change type;

[0025] A model change file is generated according to each of the change types.

[0026] Optionally, generating a model change file according to each change type includes:

[0027] If the change type is a newly added node, a node adding statement is created according to the file content of the newly added node in the metamodel definition file;

[0028] If the change type is to delete a node, creating a node deletion statement according to the file content of the deleted node in the field model file;

[0029] If the change type is to modify a node, creating a node modification statement according to the file content of the modified node in the metamodel definition file;

[0030] All of the node adding statements, the node deleting statements and the node modifying statements are combined to generate a model change file.

[0031] Optionally, the using the model change file to generate an incremental update script and updating the on-site production database includes:

[0032] Determine the target data definition language according to the database type and database version corresponding to the on-site production database;

[0033] Generate an incremental update script corresponding to the model change file according to the target data definition language;

[0034] In response to the input script execution instruction, the incremental update script is executed to update the on-site production database.

[0035] A second aspect of the present invention provides a device for generating an incremental script of a database, which is applied to a distributed version control system, wherein the distributed version control system is communicatively connected to a low-code platform, and the device comprises:

[0036] A metamodel file generation module, for generating a metamodel definition file in response to a business form operation received from the low-code platform;

[0037] A model change determination module, for comparing the metamodel definition file and the field model file when receiving a version release instruction, and generating a model change file according to the comparison result;

[0038] The script generation update module is used to generate an incremental update script using the model change file and update the on-site production database.

[0039] A third aspect of the present invention provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the incremental script generation method for a database as described in any one of the first aspect of the present invention.

[0040] A fourth aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed, implements the method for generating an incremental script for a database as described in any one of the first aspects of the present invention.

[0041] It can be seen from the above technical solutions that the present invention has the following advantages:

[0042] The present invention generates a metamodel definition file by responding to the business form operation received from the low-code platform through a distributed version control system; when a version release instruction is received, the metamodel definition file and the field model file are compared, and a model change file is generated according to the comparison result; the model change file is used to generate an incremental update script and update the field production database. Thus, by combining the editing of the distributed version control system and the low-code platform, the script update efficiency is effectively improved while maintaining the convenience of script updates for the field environment database. At the same time, the low-code platform generates a model difference file based on the metamodel definition comparison, and then converts it into the dialect of different manufacturers' databases through different database language characteristics, which increases the versatility of the product and can be flexibly adapted according to the customer's intentions for the database manufacturer. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0044] Figure 1 A flowchart of the steps of a method for generating an incremental script of a database provided by an embodiment of the present invention;

[0045] Figure 2 A schematic diagram of a metamodel definition file provided by an embodiment of the present invention;

[0046] Figure 3 A comparative schematic diagram of a memory form object tree provided by an embodiment of the present invention;

[0047] Figure 4 A schematic diagram of a model change file provided by an embodiment of the present invention;

[0048] Figure 5A structural block diagram of a device for generating incremental scripts for a database provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0049] The embodiments of the present invention provide a method, device, equipment and medium for generating incremental scripts of a database, which are used to solve the technical problem that the existing solutions usually still require manual comparison and script writing when updating scripts in the field database, resulting in low script updating efficiency of the field environment database.

[0050] In order to make the purpose, features and advantages of the present invention more obvious and easy to understand, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described below are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0051] See also Figure 1 , Figure 1 A flowchart of the steps of a method for generating an incremental script of a database provided by an embodiment of the present invention.

[0052] The present invention provides a method for generating an incremental script of a database, which is applied to a distributed version control system, wherein the distributed version control system is connected to a low-code platform for communication, and the method includes:

[0053] Step 101, generating a metamodel definition file in response to a business form operation received from a low-code platform;

[0054] A low-code platform is a software development tool designed to enable users to quickly create applications with less manual coding. It simplifies the software development process, improves development efficiency, shortens project delivery cycles, and makes application development more efficient and convenient through visual interfaces, pre-built components, and automated processes.

[0055] The distributed version control system refers to Git. Its distributed characteristics allow each developer to have a complete copy of the project repository locally, which can be operated offline and synchronized to the remote repository after the network is restored, greatly improving development flexibility and autonomy.

[0056] In an embodiment of the present application, after the user logs in to the low-code platform, the business form operation is performed on the low-code platform to create a business form. Specifically, the user finds the menu options or function entries related to form creation on the low-code platform, and clicks the corresponding button to enter the operation page for form creation; on this operation page, the user can drag, click, enter, and select operations to select the required elements from the form element library provided by the low-code platform and place them on the operation page, such as text boxes, drop-down boxes, radio buttons, text fields, and buttons; at the same time, the form elements can also be reasonably arranged through the layout tools provided by the platform to ensure that the form interface is clear, beautiful, and easy to operate; in addition, the data source associated with the form, the required validation rules and test rules, etc. can also be specified to obtain a business form.

[0057] At the same time, the distributed version control system, namely Git, uses the business form as the data basis to generate a corresponding metamodel definition file, which includes but is not limited to data such as table name, field name, field type and field length.

[0058] In an example of the present application, step 101 may include the following sub-steps:

[0059] In response to the business form operation received from the low-code platform, create a business form on the low-code platform;

[0060] Parse business forms and extract corresponding form structures and field information;

[0061] Create an initial model file that matches the form structure according to the preset model file format;

[0062] Load the field information in the initial model file and generate the metamodel definition file.

[0063] In this embodiment, the user triggers the button on the low-code platform by executing the business form operation to create a business form. At the same time, Git parses the business form, extracts the specific form structure and each field information from it, creates an initial model file matching the form structure in accordance with the preset model file format such as JSON, XML or YAML, and then loads each field information in the field position therein, thereby generating a metamodel definition file.

[0064] The metamodel definition file is a file used to describe key information such as the structure, characteristics, and constraints of the model itself. It defines various models in a specific field from a relatively abstract and high-level perspective, just like a description file that sets rules and frameworks for other models. It can be understood as the "instructions" of the model, which stipulates what components the model has, how the components are related, and what properties they have. Figure 2As shown, it is a partial schematic diagram of a metamodel definition file in JSON format with a project name of "Ship Project".

[0065] In another example of the present application, the method further includes the following steps:

[0066] In response to the form change operation received from the low-code platform, the metamodel definition file is updated to obtain a new metamodel definition file.

[0067] In this embodiment, during the version development process on the low-code platform, the user may propose a change requirement for the above-mentioned ship project due to user needs or other factors. At this time, the low-code platform receives the form change operation input by the user and changes the business form. At the same time, Git synchronously updates the metamodel definition file according to the changed part and generates a new metamodel definition file until all development requirements are completed.

[0068] In one example of the present application, the distributed version control system is further connected to a development environment database, and the method further includes:

[0069] Parse the metamodel definition file and generate the corresponding DDL statements;

[0070] Load and execute DDL statements to update the database table structure in the development environment database.

[0071] In this embodiment, different development environment databases (such as MySQL, Oracle, SQL Server, etc.) have different DDL (Data Definition Language) syntax specifications. First, clarify the database type used by the project development environment, and then generate DDL statements according to the syntax rules corresponding to the database. If the form is subsequently changed, such as adding new fields or modifying field types, the metamodel definition file must be updated accordingly and the correct DDL statements must be regenerated. You can connect to the development environment database through a database client tool (such as MySQL Workbench for MySQL database, etc.), enter the generated DDL statements in the corresponding query execution interface and execute them, thereby updating the database table structure to keep it consistent with the metamodel definition file corresponding to the business form. Or embed the logic of executing DDL statements in the application code (such as in the project's initialization script or database migration script), and automatically execute these statements to update the database when the project is started or the database migration operation is performed.

[0072] Step 102, when a version release instruction is received, the metamodel definition file and the field model file are compared, and a model change file is generated according to the comparison result;

[0073] In this embodiment, when the distributed version control system receives a version release instruction, it indicates that all development requirements have been completed and the test environment has been verified. The metamodel definition file is released to the on-site production environment. The on-site production environment usually also has a field version of the field model file. In order to know the difference between the two and to effectively update the field model file, the metamodel definition file and the field model file can be compared. The current version of the model file and the existing version of the field environment are compared, and the model change file is determined according to the comparison results to find out which files in the metamodel definition file are newly added, which files are modified, and which files are deleted.

[0074] Specifically, you can also use the git diff command in Git to compare the differences of the same file in different submissions, and the output results will be displayed in a standard difference format.

[0075] In another example of the present application, after receiving the version release instruction, the distributed version control system can also first compare the version numbers of the metamodel definition file and the field model file. If the version numbers are different, the metamodel file that has changed between the two versions is obtained.

[0076] In an example of the present application, step 102 may include the following sub-steps S11-S15:

[0077] S11, when receiving the version release instruction, respectively parse the metamodel definition file and the field model file to obtain the definition data structure and the field data structure;

[0078] S12, creating and associating tree nodes according to the defined data structure to generate a first memory form object tree;

[0079] S13, creating and associating tree nodes according to the on-site data structure to generate a second memory form object tree;

[0080] In this embodiment, when the distributed version control system receives the version release instruction, the stored metamodel definition file and the field model file are parsed, and the files are parsed into definition data structures and field data structures that can be processed by the program, such as a combination of dictionaries and lists. Tree nodes are constructed according to the parsed content. According to the database characteristics, the table name, field name, field type and field length are used to construct a unique tree node name. The tree nodes are organized according to a hierarchical relationship to form a memory form object tree. Usually, the table name can be used as the root node of the tree, and the field-related nodes are connected to the corresponding table nodes as child nodes. For multiple fields of each table, their nodes should be connected to the corresponding table root node in the tree to form a complete tree structure, thereby obtaining a first memory form object tree and a second memory form object tree as a data basis for subsequent comparison.

[0081] When constructing the tree node name, the tree node name is uniquely constructed according to the database characteristics, table name, field name, field type, and field length. For fields with integer length, special words can be used to represent them.

[0082] S14, recursively traverse the first memory form object tree and the second memory form object tree to determine the change type;

[0083] In the embodiment of the present application, by recursively traversing the first memory form object tree and the second memory form object tree, for each node, the current node is first processed, and then its child nodes are recursively processed to determine the change type of each tree node between the trees. Specifically, when comparing tree nodes, the content of the comparison includes table name, field name, field type and field length, and the change type is determined, such as Figure 3 shown.

[0084] For example, if the node node1 in the first memory form object tree and the node node2 in the second memory form object tree have the same node name, their properties are further compared:

[0085] Table name comparison: Check if node1.table_name is equal to node2.table_name.

[0086] Field name comparison: Checks if node1.field_name is equal to node2.field_name.

[0087] Field type comparison: Check if node1.field_type is equal to node2.field_type.

[0088] Field length comparison: Check if node1.field_length is equal to node2.field_length.

[0089] If all node attributes are the same, it means that the node has not changed. If the table name, field name, field type or field length has changed, it is determined that the node has changed, and its change type is further determined. For example:

[0090] Newly added node: If there is a node in the second memory form object tree and no corresponding node is found in the first memory form object tree, then the node is a newly added node.

[0091] Deleting a node: If there is a node in the first memory form object tree and no corresponding node is found in the second memory form object tree, then the node is a deleted node.

[0092] Modified node: If a node exists in both trees but its attributes have changed, then the node is a modified node.

[0093] S15. Generate a model change file according to each change type.

[0094] Furthermore, S15 may include the following sub-steps:

[0095] If the change type is adding a new node, create a node adding statement according to the file content of the new node in the metamodel definition file;

[0096] If the change type is to delete a node, a node deletion statement is created according to the file content of the deleted node in the on-site model file;

[0097] If the change type is to modify a node, a node modification statement is created according to the file content of the modified node in the metamodel definition file;

[0098] Combine all node addition statements, node deletion statements, and node modification statements to generate a model change file.

[0099] In the embodiment of the present application, if the change type is a new node, it indicates that a Git file has been added. At this time, the corresponding file content can be located from the metamodel definition file according to the table name of the new node, and the corresponding node addition statement is generated according to the file content. If the change type of the tree node is a deleted node, it indicates that the part of the file has been deleted during the version update process, but still exists in the field model file. The file content in the field model file can be located according to the table name of the deleted node, and a node deletion statement is created.

[0100] For the part of the tree node whose change type is to modify the node, since the table name has not changed, only the node attribute, that is, the field part, has changed, the corresponding file content can be located in the metamodel definition file according to the table name of the modified node, and the node modification statement can be created according to the specific changes in its node attributes. Among them, the changes in node attributes include but are not limited to the addition of fields, deletion of fields, change of field names, change of field lengths, and change of field types, and different node modification statements are generated for different changes.

[0101] After traversing all change types, all node addition statements, node deletion statements, and node modification statements are combined to generate a model change file, such as Figure 4 shown.

[0102] Step 103: Generate an incremental update script using the model change file and update the on-site production database.

[0103] In an example of the present application, step 103 may include the following sub-steps:

[0104] Determine the target data definition language according to the database type and database version corresponding to the on-site production database;

[0105] Generate an incremental update script corresponding to the model change file according to the target data definition language;

[0106] In response to the input script execution instruction, the incremental update script is executed to update the on-site production database.

[0107] In this embodiment, the database model and version used by the on-site production database may be different from the distributed version control system, and different database types and versions have differences in DDL syntax. For example, MySQL and Oracle have different syntaxes for operations such as creating tables and modifying fields.

[0108] Therefore, after generating the model change file, determine the corresponding target data definition language according to the database type and database version corresponding to the on-site generated database, such as MySQL, Oracle and its version, adjust the statements in the model change file according to the target data definition language, and generate the corresponding incremental update script. For example, for the addition of git files, generate a Create table script; for the deletion of git files, generate a Drop table script. According to the actual project data security scenario, the table will be renamed, the business will be unavailable, but the data will be retained; for git file changes, generate an add column script according to the addition of its fields, generate a delete column script for field deletion, generate an altercloumn script for field name and length changes, and generate a delete column script for field before change and an addcolumn script for field after change if the field type is changed.

[0109] There may be multiple on-site production databases at the same time, and the target data definition language may also include multiple languages ​​at the same time.

[0110] After the incremental update script is generated, you can respond to the input script execution instructions through the command line tool or database client tool to execute the incremental update script to update the on-site production database. For example, after executing the DDL script of the newly added table, a new table structure will appear in the database; after executing the script to modify the field type, the field type in the corresponding table will be updated. This implements the version update operation and keeps the database structure in the production environment consistent with the model structure of the new version.

[0111] In an embodiment of the present application, a distributed version control system responds to business form operations received from a low-code platform to generate a metamodel definition file; when a version release instruction is received, the metamodel definition file and the field model file are compared, and a model change file is generated according to the comparison result; the model change file is used to generate an incremental update script and update the field production database. Thus, by combining the editing of the distributed version control system and the low-code platform, the script update efficiency is effectively improved while maintaining the convenience of script updates for the field environment database. At the same time, the low-code platform generates a model difference file based on the metamodel definition comparison, and then converts it into the dialect of databases of different manufacturers through different database language characteristics, which increases the versatility of the product and can be flexibly adapted according to the customer's intentions for the database manufacturer.

[0112] See also Figure 5 , Figure 5 A structural block diagram of an incremental script generation device for a database provided in an embodiment of the present application is shown.

[0113] An embodiment of the present invention provides a device for generating incremental scripts of a database, which is applied to a distributed version control system, wherein the distributed version control system is communicatively connected with a low-code platform, and the device includes:

[0114] The metamodel file generation module 501 is used to generate a metamodel definition file in response to a business form operation received from the low-code platform;

[0115] The model change determination module 502 is used to compare the metamodel definition file and the field model file when receiving the version release instruction, and generate a model change file according to the comparison result;

[0116] The script generation and update module 503 is used to generate an incremental update script using the model change file and update the on-site production database.

[0117] Optionally, the meta-model file generating module 501 is specifically used for:

[0118] In response to the business form operation received from the low-code platform, create a business form on the low-code platform;

[0119] Parse business forms and extract corresponding form structures and field information;

[0120] Create an initial model file that matches the form structure according to the preset model file format;

[0121] Load the field information in the initial model file and generate the metamodel definition file.

[0122] Optionally, the distributed version control system is also connected to a development environment database, and the device further includes:

[0123] The statement generation module is used to parse the metamodel definition file and generate the corresponding DDL statements;

[0124] The development database update module is used to load and execute DDL statements to update the database table structure in the development environment database.

[0125] Optionally, the device further comprises:

[0126] The change update module is used to respond to the form change operation received from the low-code platform, update the metamodel definition file, and obtain a new metamodel definition file.

[0127] Optionally, the model change determination module 502 includes:

[0128] The file parsing submodule is used to parse the metamodel definition file and the field model file respectively to obtain the definition data structure and the field data structure when receiving the version release instruction;

[0129] A first object tree generation submodule, used to create and associate tree nodes according to a defined data structure to generate a first memory form object tree;

[0130] A second object tree generation submodule is used to create and associate tree nodes according to the field data structure to generate a second memory form object tree;

[0131] A recursive comparison submodule, used for recursively traversing the first memory form object tree and the second memory form object tree to determine the change type;

[0132] The change file generation submodule is used to generate model change files according to each change type.

[0133] Optionally, the change file generation submodule is specifically used for:

[0134] If the change type is adding a new node, create a node adding statement according to the file content of the new node in the metamodel definition file;

[0135] If the change type is to delete a node, a node deletion statement is created according to the file content of the deleted node in the on-site model file;

[0136] If the change type is to modify a node, a node modification statement is created according to the file content of the modified node in the metamodel definition file;

[0137] Combine all node addition statements, node deletion statements, and node modification statements to generate a model change file.

[0138] Optionally, the script generation and updating module 503 is specifically used for:

[0139] Determine the target data definition language according to the database type and database version corresponding to the on-site production database;

[0140] Generate an incremental update script corresponding to the model change file according to the target data definition language;

[0141] In response to the input script execution instruction, the incremental update script is executed to update the on-site production database.

[0142] An embodiment of the present invention provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of the incremental script generation method for a database as described in any embodiment of the present invention.

[0143] An embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed, the method for generating an incremental script of a database as described in any embodiment of the present invention is implemented.

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

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

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

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

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

[0149] As described above, the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features thereof may be replaced by equivalents. 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 invention.

Claims

1. A method for generating an incremental script of a database, characterized in that: Applied to a distributed version control system, the distributed version control system is communicatively connected with a low-code platform, the method includes: In response to a business form operation received from the low-code platform, generate a metamodel definition file; When a version release instruction is received, the metamodel definition file and the field model file are compared, and a model change file is generated according to the comparison result; The model change file is used to generate an incremental update script and update the on-site production database.

2. The method according to claim 1, characterized in that The response to the business form operation received from the low-code platform generates a metamodel definition file, including: In response to a business form operation received from the low-code platform, create a business form on the low-code platform; Parse the business form and extract the corresponding form structure and field information; Creating an initial model file matching the form structure according to a preset model file format; The field information is loaded into the initial model file to generate a metamodel definition file.

3. The method according to claim 1 or 2, characterized in that: The distributed version control system is also connected to a development environment database, and the method further comprises: Parsing the metamodel definition file to generate corresponding DDL statements; The DDL statements are loaded and executed to update the database table structure in the development environment database.

4. The method according to claim 1, characterized in that The method further comprises: In response to the form change operation received from the low-code platform, the metamodel definition file is updated to obtain a new metamodel definition file.

5. The method according to claim 1, characterized in that When the version release instruction is received, the metamodel definition file and the field model file are compared, and a model change file is generated according to the comparison result, including: When a version release instruction is received, the metamodel definition file and the field model file are parsed respectively to obtain a definition data structure and a field data structure; Create and associate tree nodes according to the defined data structure to generate a first memory form object tree; Create and associate tree nodes according to the field data structure to generate a second memory form object tree; Recursively traverse the first memory form object tree and the second memory form object tree to determine a change type; A model change file is generated according to each of the change types.

6. The method according to claim 5, characterized in that Generating a model change file according to each change type includes: If the change type is a newly added node, a node adding statement is created according to the file content of the newly added node in the metamodel definition file; If the change type is to delete a node, creating a node deletion statement according to the file content of the deleted node in the field model file; If the change type is to modify a node, creating a node modification statement according to the file content of the modified node in the metamodel definition file; All of the node adding statements, the node deleting statements and the node modifying statements are combined to generate a model change file.

7. The method according to claim 1, characterized in that The step of using the model change file to generate an incremental update script and updating the on-site production database includes: Determine the target data definition language according to the database type and database version corresponding to the on-site production database; Generate an incremental update script corresponding to the model change file according to the target data definition language; In response to the input script execution instruction, the incremental update script is executed to update the on-site production database.

8. A device for generating incremental scripts for a database, characterized in that: Applied to a distributed version control system, the distributed version control system is communicatively connected with a low-code platform, and the device includes: A metamodel file generation module, for generating a metamodel definition file in response to a business form operation received from the low-code platform; A model change determination module, for comparing the metamodel definition file and the field model file when receiving a version release instruction, and generating a model change file according to the comparison result; The script generation update module is used to generate an incremental update script using the model change file and update the on-site production database.

9. An electronic device, characterized in that: It comprises a memory and a processor, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the processor executes the steps of the incremental script generation method for a database as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed, the incremental script generation method for a database as described in any one of claims 1 to 7 is implemented.

Images