Version processing method, device and electronic device for structured object data

Abstract

The present application discloses a version processing method, device and electronic device for structured object data. The method includes: determining a version data space for storing historical version data of structured object data, wherein the version data space stores at least an object version snapshot table, an object index snapshot table and a project version information table; generating new version data of any structured object data and writing it into the version data space; generating new version data of the entire project and writing it into the version data space; determining the original structure data of the historical version of the target object from the object version snapshot table; and determining the object index list of the target project version from the object index snapshot table and the project version information table. The present application solves the technical problem in the prior art that when performing version management on structured object data, new versions and historical versions are mixed together, affecting normal access to the system.

Description

Technical Field

[0001] The present application relates to the field of data management, and in particular to a method, device and electronic device for version processing of structured object data. Background Art

[0002] In the control system field, controller programming, control signal mapping, monitoring screen rendering, and alarm definition are all part of the configuration process. The data generated during the configuration process is typically structured data, and archives of this data are called configuration archives. Configuration archives need to be released to the production environment for debugging and operation. The configuration process is separate from the production process. Production typically uses the latest version of the configuration archive for production. Engineers can also continuously adjust and optimize the configuration archive. Therefore, configuration archives require version management. Each configuration archive released to the production environment is stored and managed as a single version. This ensures that ongoing configuration changes do not affect the configuration archive in production, and allows for restoration to a previous version in the event of errors in the new modification. During debugging, engineers frequently modify and release configuration archives. Simply backing up the entire configuration archive for each release wastes storage space, slows down the release process, and hinders debugging.

[0003] For version management of structured data, a version number field is usually added to the database. When a new version is generated, a record with the new version number is inserted. This causes the latest version and historical versions to be mixed together. When the data volume itself is large, and historical versions are added, the data volume problem will seriously affect the normal access of the system.

[0004] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0005] The embodiments of the present application provide a method, device, and electronic device for version processing of structured object data, so as to at least solve the technical problem in the prior art of mixing new versions and historical versions when performing version management on structured object data, thereby affecting normal access to the system.

[0006] According to one aspect of an embodiment of the present application, a version processing method for structured object data is provided, including: determining a version data space for storing historical version data of structured object data, wherein the version data space stores at least an object version snapshot table, an object index snapshot table, and a project version information table, the object version snapshot table being used to store object version snapshot information of each version of each object, the object index snapshot table being used to store index snapshot information of all structured object data of each version of a project, and the project version information table being used to store version submission information corresponding to each version of a project; generating new version data of any structured object data, and writing the new version data of the structured object data into the version data space; generating new version data of the entire project, and writing the new version data of the entire project into the version data space, wherein the new version data of the entire project consists of the new version data of the structured object data; obtaining snapshot data corresponding to the historical version of a target object from the object version snapshot table, and determining original structure data of the historical version of the target object based on the snapshot data; determining an object index snapshot data fingerprint corresponding to the historical version of a target project from the object index snapshot table and the project version information table, and determining an object index list of the target project version based on the object index snapshot data fingerprint.

[0007] Optionally, the object version snapshot information includes the object ID, the object version number, the object snapshot data, and the data fingerprint of the object snapshot data; the index snapshot information includes the snapshot data of the object list consisting of the IDs and version numbers of all objects and the data fingerprint of the snapshot data; the version submission information includes the version submitter, the version submission time, the project version number, the version submission remarks, and the data fingerprint of the object index snapshot data of the project version.

[0008] Optionally, new version data of any structured object data is generated, and the new version data of the structured object data is written into the version data space, including: obtaining the object to be generated with a new version, and generating a new version number for the object to be generated with a new version, wherein the object to be generated with a new version is an object that has changed in a working environment; serializing the original structure data of the new version object to obtain serialized data of the new version object; encoding and compressing the serialized data of the new version object to obtain snapshot data of the new version object; determining a data fingerprint of the snapshot data based on the snapshot data of the new version object; generating row data based on the object ID, version number, snapshot data and data fingerprint of the new version object, and storing the row data in the object version snapshot table of the version data space.

[0009] Optionally, new version data for the entire project is generated and written into the version data space, including: traversing all objects in the entire project to determine a project object index list, wherein the project object index list includes the object IDs and version numbers of all objects; performing serialization operations on the project object index list to generate serialized data of the project object index list; encoding and compressing the serialized data of the project object index list to generate snapshot data of the object index; determining a data fingerprint of the object index snapshot data based on the object index snapshot data; and storing the object index snapshot data and the data fingerprint of the object index snapshot as row data into the object index snapshot table of the version data space.

[0010] Optionally, the method further includes: storing the submitter, submission time, new project version number, new version remarks and data fingerprint of the object index snapshot of the new version data of the entire project as row data in the project version information table of the version data space.

[0011] Optionally, snapshot data corresponding to the historical version of the target object is obtained from the object version snapshot table, and the original structural data of the historical version of the target object is determined based on the snapshot data, including: obtaining first information or second information of the historical version of the target object, wherein the first information includes the object ID and version number of the historical version of the target object, and the second information includes the data fingerprint of the historical version of the target object; querying the snapshot data corresponding to the first information or the second information from the object version snapshot table; decoding the snapshot data corresponding to the first information or the second information to obtain serialized data of the historical version of the object to be loaded; and performing a deserialization operation on the serialized data of the historical version of the object to be loaded to obtain the original structural data of the historical version of the target object.

[0012] Optionally, obtaining the first information or the second information of the historical version of the target object includes: obtaining the object ID of the target object, wherein the object ID of the target object is the object ID of any object in the historical evolution process of the project; querying all historical version information corresponding to the object ID from the object version snapshot table, wherein the historical version information includes the version number of the historical version of the target object and the snapshot data fingerprint of the historical version of the target object.

[0013] Optionally, determining the object index list of the target project version includes: obtaining the historical version number of the target project, wherein the historical version number of the target project is the version number in any row of data in the project version information table; querying the object index snapshot data fingerprint corresponding to the historical version number of the target project from the project version information table; querying the object index snapshot data corresponding to the object index snapshot data fingerprint from the object index snapshot; decoding the object index snapshot data to obtain the object index list of the historical version of the target project.

[0014] According to another aspect of an embodiment of the present application, a version processing device for structured object data is provided, comprising: a determination module for determining a version data space storing historical version data of the structured object data, wherein the version data space stores at least an object version snapshot table, an object index snapshot table, and a project version information table, the object version snapshot table being used to store object version snapshot information of each version of each object, the object index snapshot table being used to store index snapshot information of all structured object data of each version of a project, and the project version information table being used to store version submission information corresponding to each version of the project; a first generation module for generating new version data of any structured object data and writing the new version data of the structured object data into the version data space; a second generation module for generating new version data of the entire project and writing the new version data of the entire project into the version data space, wherein the new version data of the entire project consists of the new version data of the structured object data; a first determination module for obtaining snapshot data corresponding to a historical version of a target object from the object version snapshot table and determining original structure data of the historical version of the target object based on the snapshot data; and a second determination module for determining an object index snapshot data fingerprint corresponding to the historical version of the target project from the object index snapshot table and the project version information table, and determining an object index list of the target project version based on the object index snapshot data fingerprint.

[0015] According to another aspect of an embodiment of the present application, an electronic device is further provided, comprising: a memory for storing program instructions; a processor, connected to the memory, for executing program instructions that implement the following functions: determining a version data space for storing historical version data of structured object data, wherein the version data space stores at least an object version snapshot table, an object index snapshot table, and a project version information table, the object version snapshot table being used to store object version snapshot information of each version of each object, the object index snapshot table being used to store index snapshot information of all structured object data of each version of a project, and the project version information table being used to store version submission information corresponding to each version of the project; generating new version data of any structured object data, and writing the new version data of the structured object data into the version data space; generating new version data of the entire project, and writing the new version data of the entire project into the version data space, wherein the new version data of the entire project consists of the new version data of the structured object data; obtaining snapshot data corresponding to the historical version of a target object from the object version snapshot table, and determining original structure data of the historical version of the target object based on the snapshot data; determining an object index snapshot data fingerprint corresponding to the historical version of the target project from the object index snapshot table and the project version information table, and determining an object index list of the target project version based on the object index snapshot data fingerprint.

[0016] According to another aspect of an embodiment of the present application, a non-volatile storage medium is provided, which includes a stored program, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the above-mentioned version processing method for structured object data.

[0017] In the embodiment of the present application, the historical version data of objects and projects is stored in a dedicated version data space, thereby achieving the purpose of version management of structured object data and realizing the technical effect of separating working data and historical version data, thereby solving the technical problem in the prior art of version management of structured object data, in which new versions and historical versions are mixed together, affecting normal access to the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0019] Figure 1 This is a hardware structure block diagram of a computer terminal (or electronic device) for implementing a version processing method for structured object data according to an embodiment of the present application;

[0020] Figure 2 is a flowchart of a method for processing structured object data versions according to an embodiment of the present application;

[0021] Figure 3 This is a flow chart of determining original structure data of a historical version of a target object based on snapshot data according to an embodiment of the present application;

[0022] Figure 4 is a flow chart of determining an object index list of a target project version according to an embodiment of the present application;

[0023] Figure 5 It is a structural diagram of a version processing device for structured object data according to an embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

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

[0026] First, some nouns or terms that appear in the description of the embodiments of the present application are subject to the following interpretations:

[0027] Structured data, also known as row data, is logically represented and implemented using a two-dimensional table structure. It strictly adheres to data format and length specifications and is primarily stored and managed in relational databases. In contrast to structured data, unstructured data is not well-suited to two-dimensional database tables. This includes office documents of all formats, XML, HTML, various reports, images, audio, and video information.

[0028] Snapshot: It is a data protection technology in storage systems. Each snapshot is a copy of the data at a certain point in time.

[0029] Data fingerprint: A unique identifier obtained by hashing the data, that is, a string of characters, used to determine the uniqueness of the data and whether the data has been tampered with or lost, in order to ensure the integrity of the file or data.

[0030] In the related art, unstructured data (file-type data) is usually managed using common version management schemes such as git / svn. These version management schemes are file-based and restrict configuration archives to file storage. They also impose strong constraints on the size and rules of configuration archive files. Since configuration archives in the control system field are mostly structured data, modifying one object may cause the properties of multiple objects to be modified. This is different from the characteristics of unstructured data. Therefore, when a configuration is modified, it is very likely to cause changes in multiple data locations. When the granularity of the configuration archive file is too large, a small modification will result in a change in the configuration archive file and a new version will be generated. Since git / svn's historical versions are stored in full, the space occupied by the version repository will increase rapidly. If the granularity of the configuration archive file is reduced, such as creating a file with object granularity, a large number of small files will be generated. The presence of a large number of small files in the configuration archive will have a huge impact on the access performance of the file. In general, it is difficult to implement version management of structured data using git / svn.

[0031] In an optional version management method, file-based version management is stored in a database system rather than a file system. It can only manage file versions, and this is inconsistent with the configuration archiving rules in the control system field. In addition to version management, the control system configuration archive also needs to perform a publishing action to publish the latest version of the configuration archive to run in a monitoring environment. If the historical version and the latest version archive are mixed together, it is difficult to extract the latest version archive, and it is difficult to adapt to the release process of the control system configuration archive.

[0032] To solve the above problems, the embodiments of the present application provide corresponding solutions, which are described in detail below.

[0033] The version processing method embodiment of structured object data provided in the embodiment of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 The hardware structure block diagram of a computer terminal (or electronic device) for implementing a version processing method for structured object data is shown. Figure 1 As shown, the computer terminal 10 (or electronic device 10) may include one or more (illustrated by 102a, 102b, ..., 102n in the figure) processors (the processor may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission module 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a power supply and / or a camera. It will be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0034] It should be noted that the one or more processors and / or other data processing circuits described above may generally be referred to herein as "data processing circuitry." The data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuitry may be a single, independent processing module, or may be incorporated in whole or in part into any of the other components of the computer terminal 10 (or electronic device). As described in the embodiments of the present application, the data processing circuitry serves as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0035] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the version processing method of structured object data in the embodiment of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, implementing the above-mentioned version processing method of structured object data. The memory 104 may include a high-speed random access memory and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely located relative to the processor, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0036] The transmission module 106 is configured to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by the communications provider of the computer terminal 10. In one embodiment, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, the transmission device 106 may be a radio frequency (RF) module, which is configured to communicate with the Internet wirelessly.

[0037] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 (or electronic device).

[0038] It should be noted that, in some optional embodiments, the above Figure 1 The computer device (or electronic device) shown may include hardware elements (including circuits), software elements (including computer code stored on a computer-readable medium), or a combination of hardware elements and software elements. Figure 1 This is merely one example of a particular embodiment and is intended to illustrate the types of components that may be present in the computer device (or electronic device) described above.

[0039] In the above-mentioned operating environment, an embodiment of the present application provides an embodiment of a version processing method for structured object data. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0040] Figure 2 is a flowchart of a method for processing a version of structured object data according to an embodiment of the present application, such as Figure 2 As shown, the method includes the following steps:

[0041] Step S201, determine the version data space for storing historical version data of structured object data, wherein the version data space stores at least an object version snapshot table, an object index snapshot table and a project version information table, the object version snapshot table is used to store the object version snapshot information of each version of each object, the object index snapshot table is used to store the index snapshot information of all structured object data of each version of the project, and the project version information table is used to store the version submission information corresponding to each version of the project.

[0042] Specifically, the method includes the following sub-steps:

[0043] Sub-step S201.01, defining a version data space, which can be a new database instance of a service-based relational database such as MYSQL, ORACLE, or SQLSERVER, or a new database file of a file-based relational database such as SQLITE;

[0044] Sub-step S201.02: Define an object version snapshot table. The object version snapshot table is used to store the object version snapshot information of each version of each object. The object version snapshot information includes the object ID, the object version number, the object snapshot data, and the data fingerprint of the object snapshot data. Specifically, the structure of the object version snapshot table is defined as follows:

[0045]

[0046]

[0047] Sub-step S201.03: Define an object index snapshot table. The object index snapshot table is used to store index snapshot information for all objects in each version of the project. The index snapshot information contains snapshot data of an object list consisting of all object IDs and object version numbers, as well as the data fingerprint of the snapshot data. Specifically, the structure of the object index snapshot table is defined as follows:

[0048]

[0049] Sub-step S201.04 defines a project version information table. The project version information table is used to store the version submission information corresponding to each project version. The version submission information includes the version submitter, version submission time, project version number, version submission notes, and the data fingerprint of the object index snapshot data of the project version. Specifically, the structure of the project version information table is defined as follows:

[0050]

[0051] Step S202: Generate new version data of any structured object data and write the new version data of the structured object data into the version data space. Specifically, it includes the following sub-steps:

[0052] Sub-step S202.01, determining the object for which a new version is to be generated. The object for which a new version is to be generated refers to an object that has changed in the working environment, such as a modified or newly added object. In a specific embodiment, whether the object's version number is greater than zero can be used to determine whether a new version is required. The version number of a newly added object is 0, and the version number of a modified object is the absolute value of the current object version number, which is negative.

[0053] Sub-step S202.02: Generate a new version number for the object to be updated. In a specific embodiment, the absolute value of the object's current version number plus 1 can be used as the new version number.

[0054] Sub-step S202.03: Serialize the original structure data of the new version object to obtain serialized data of the new version object. In a specific embodiment, for the compatibility of the object version structure and identification of the object type, the object version number and object type identifier are used as the header data of the serialized data;

[0055] Sub-step S202.04: Encode and compress the serialized data of the new version object to obtain snapshot data of the new version object. In a specific embodiment, the serialized data can be compressed using algorithms such as zip, lz4, or gzip;

[0056] Sub-step S202.05: hash the snapshot data of the new version object to obtain a data fingerprint of the snapshot data. In a specific embodiment, a hash algorithm such as SHA-1, SHA-256, or SHA-512 may be used for the hash operation;

[0057] Sub-step S202.06: Generate row data based on the object ID, version number, snapshot data, and data fingerprint of the new version object, and store the row data in the object version snapshot table of the version data space.

[0058] Step S203 : Generate new version data of the entire project, and write the new version data of the entire project into the version data space, wherein the new version data of the entire project consists of new version data of structured object data.

[0059] The above step S203 includes the following sub-steps:

[0060] Sub-step S203.01, determining the submitter, submission time, new project version number, and new version notes for the new project version. In a specific embodiment, the submitter for the new project version is the operator who performed the operation, the submission time is the current system time when the operation was performed, the new project version number is the current project version number + 1, and the new version notes are the notes entered by the current operator.

[0061] Sub-step S203.02, traverse all objects in the entire project, extract the object ID and version number of all objects, and form a project object index list. In a specific embodiment, in order to more quickly compare the differences between two project versions, an ordered project object index list is used;

[0062] Sub-step S203.03, performing a serialization operation on the engineering object index list to generate serialized data of the engineering object index list;

[0063] Sub-step S203.04: Encode and compress the serialized data of the engineering object index list to generate snapshot data of the object index. In a specific embodiment, the compression algorithm used here is generally the same as the compression algorithm used in step S202.05;

[0064] Sub-step S203.05: hash the snapshot data of the object index to obtain the data fingerprint of the object index snapshot. In a specific embodiment, the hash algorithm used here is generally the same as the hash algorithm used in step S202.05;

[0065] Sub-step S203.06, storing the object index snapshot data and the data fingerprint of the object index snapshot as row data in the object index snapshot table of the version data space;

[0066] Sub-step S203.07 stores the submitter, submission time, new project version number, new version remarks, and data fingerprint of the object index snapshot of the new version data of the entire project as row data in the project version information table of the version data space.

[0067] In the above steps S201 to S203, a new database instance is used to store the historical versions of the object, separating the historical version data from the working data. It should be noted that the working data can be understood as the data corresponding to the currently used version, or the data used in the workspace, so that the inventory of historical version data does not affect the performance of the working data. After all, the retention of the historical version data of the object is mainly to solve the traceability problem of the object data, and there is no need to access the historical version data of the object at high frequency.

[0068] Step S204 : obtaining snapshot data corresponding to the historical version of the target object from the object version snapshot table, and determining the original structure data of the historical version of the target object based on the snapshot data.

[0069] In the above step S204, the snapshot data corresponding to the historical version of the target object is obtained from the object version snapshot table, and the original structure data of the historical version of the target object is determined based on the snapshot data, such as Figure 3 As shown, the specific steps include:

[0070] Step S301: Acquire first information or second information of a historical version of a target object, wherein the first information includes an object ID and a version number of the historical version of the target object, and the second information includes a data fingerprint of the historical version of the target object.

[0071] In the above step S301, the object ID of the target object can be the object ID of any object in the historical evolution process of the project. All historical version information corresponding to the object ID is queried from the object version snapshot table of the version data space. The historical version information includes the version number of the historical version of the target object and the snapshot data fingerprint of the historical version of the target object.

[0072] Step S302, query the snapshot data corresponding to the first information or the second information from the object version snapshot table, that is, query the snapshot data corresponding to the object ID and version number of the historical version of the target object from the object version snapshot table of the version data space, or query the snapshot data corresponding to the data fingerprint of the historical version of the target object from the object version snapshot table of the version data space.

[0073] Step S303: Decode the snapshot data corresponding to the first information or the second information to obtain serialized data of the historical version of the object to be loaded;

[0074] Step S304 : performing a deserialization operation on the serialized data of the historical version of the target object to be loaded, and obtaining the original structure data of the historical version of the target object.

[0075] Through the method in steps S301 to S304 above, the data differences between any two historical versions of the target object can be compared. Specifically, the data differences between any two historical versions of the target object can be compared using Figure 3 The method shown compares the data differences between a workspace object and any historical version of the object.

[0076] Step S205: Determine the object index snapshot data fingerprint corresponding to the target project historical version from the object index snapshot table and the project version information table, and determine the object index list of the target project version based on the object index snapshot data fingerprint, wherein the object index list is used to compare the differences between different versions.

[0077] In the above step S205, the object index list of the target project version is determined, such as Figure 4 The flowchart shown specifically includes the following steps:

[0078] Step S401, obtaining the target project history version number, wherein the target project history version number is the version number in any row of data in the project version information table;

[0079] Step S402: query the object index snapshot data fingerprint corresponding to the target project's historical version number from the project version information table;

[0080] Step S403: querying the object index snapshot data corresponding to the object index snapshot data fingerprint from the object index snapshot;

[0081] Step S404: Decode the object index snapshot data to obtain an object index list of the target project's historical version.

[0082] By using the method in steps S401 to S404 above, the change lists of the added, modified, and deleted states of objects between any two historical versions of the project can be compared.

[0083] The embodiment of the present application provides a version processing method for structured object data, which can solve the problem of engineering-level structured data version management. It not only performs version management on a single structured object, but also supports version management on the entire engineering data.

[0084] A method for processing structured data provided by an embodiment of the present application has the following advantages: 1) supports object-level version management, each version of an object is a complete data snapshot of the object, and the complete historical version object can be directly obtained without incremental comparison; 2) supports project-level version management, each version of the project is a snapshot of the object directory, and the project-level historical version data is incremental, saving storage space for historical version data; 3) supports access to historical versions of a single object and also supports access to historical versions of the project; 4) historical version data and working data are separated, without affecting business logic and performance.

[0085] Figure 5 is a structural diagram of a version processing device for structured object data according to an embodiment of the present application, such as Figure 5 As shown, the device includes:

[0086] Determining module 502 is configured to determine a version data space for storing historical version data of structured object data, wherein the version data space stores at least an object version snapshot table, an object index snapshot table, and a project version information table. The object version snapshot table is configured to store object version snapshot information for each version of each object. The object index snapshot table is configured to store index snapshot information for all structured object data of each version of a project. The project version information table is configured to store version submission information corresponding to each version of the project.

[0087] A first generating module 504 is configured to generate new version data of any structured object data and write the new version data of the structured object data into the version data space;

[0088] A second generating module 506 is configured to generate new version data of the entire project and write the new version data of the entire project into the version data space, wherein the new version data of the entire project consists of the new version data of the structured object data;

[0089] A first determining module 508 is configured to obtain snapshot data corresponding to a historical version of a target object from an object version snapshot table, and determine original structure data of the historical version of the target object based on the snapshot data;

[0090] The second determination module 510 is used to determine the object index snapshot data fingerprint corresponding to the historical version of the target project from the object index snapshot table and the project version information table, and determine the object index list of the target project version based on the object index snapshot data fingerprint, wherein the object index list is used to compare the differences between different versions.

[0091] It should be noted that Figure 5 The version processing device of the structured object data shown is used to implement Figure 2The version processing method of structured object data shown in the figure, therefore, the relevant explanations in the above-mentioned version processing method of structured object data are also applicable to the version processing device of structured object data, and are not repeated here.

[0092] The embodiment of the present application also provides a non-volatile storage medium, which includes a stored program, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the following version processing method for structured object data: determining a version data space for storing historical version data of structured object data, wherein the version data space stores at least an object version snapshot table, an object index snapshot table and a project version information table, the object version snapshot table is used to store object version snapshot information of each version of each object, the object index snapshot table is used to store index snapshot information of all structured object data of each version of the project, and the project version information table is used to store version submission information corresponding to each version of the project; generating any structure New version data of the structured object data is generated, and the new version data of the structured object data is written into the version data space; new version data of the entire project is generated, and the new version data of the entire project is written into the version data space, wherein the new version data of the entire project is composed of the new version data of the structured object data; snapshot data corresponding to the historical version of the target object is obtained from the object version snapshot table, and the original structure data of the historical version of the target object is determined based on the snapshot data; the object index snapshot data fingerprint corresponding to the historical version of the target project is determined from the object index snapshot table and the project version information table, and the object index list of the target project version is determined based on the object index snapshot data fingerprint, wherein the object index list is used to compare the differences between different versions.

[0093] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0094] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

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

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

[0097] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0098] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0099] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A version processing method for structured object data, characterized in that: include: Determine a version data space for storing historical version data of structured object data, wherein the version data space stores at least an object version snapshot table, an object index snapshot table, and a project version information table, wherein the object version snapshot table is used to store object version snapshot information of each version of each object, the object index snapshot table is used to store index snapshot information of all structured object data of each version of the project, and the project version information table is used to store version submission information corresponding to each version of the project; Generate new version data of any structured object data, and write the new version data of the structured object data into the version data space; generating new version data of the entire project, and writing the new version data of the entire project into the version data space, wherein the new version data of the entire project consists of the new version data of the structured object data; Obtaining snapshot data corresponding to a historical version of the target object from the object version snapshot table, and determining original structure data of the historical version of the target object based on the snapshot data; The object index snapshot data fingerprint corresponding to the target project history version is determined from the object index snapshot table and the project version information table, and the object index list of the target project version is determined based on the object index snapshot data fingerprint.

2. The method according to claim 1, characterized in that The object version snapshot information includes the object ID, the object version number, the object snapshot data, and the data fingerprint of the object snapshot data; The index snapshot information includes snapshot data of an object list consisting of the IDs and version numbers of all objects and a data fingerprint of the snapshot data; The version submission information includes the version submitter, version submission time, project version number, version submission remarks, and data fingerprint of the object index snapshot data of the project version.

3. The method according to claim 1, characterized in that Generating new version data of any structured object data and writing the new version data of the structured object data into the version data space, including: Acquire an object for which a new version is to be generated, and generate a new version number for the object for which a new version is to be generated, wherein the object for which a new version is to be generated is an object that has changed in a working environment; Performing a serialization operation on the original structural data of the new version object to obtain serialized data of the new version object; Encoding and compressing the serialized data of the new version object to obtain snapshot data of the new version object; Determining a data fingerprint of the snapshot data based on the snapshot data of the new version object; Generate row data based on the object ID, version number, snapshot data and data fingerprint of the new version object, and store the row data in the object version snapshot table of the version data space.

4. The method according to claim 1, wherein Generating new version data of the entire project and writing the new version data of the entire project into the version data space includes: Traversing all objects in the entire project to determine a project object index list, wherein the project object index list includes object IDs and version numbers of all objects; Performing a serialization operation on the engineering object index list to generate serialized data of the engineering object index list; Encoding and compressing the serialized data of the engineering object index list to generate snapshot data of the object index; Determining a data fingerprint of the object index snapshot data based on the object index snapshot data; The object index snapshot data and the data fingerprint of the object index snapshot are stored as row data in the object index snapshot table of the version data space.

5. The method according to claim 4, characterized in that The method further comprises: The submitter, submission time, new project version number, new version remarks and data fingerprint of the object index snapshot of the new version data of the entire project are stored as row data in the project version information table of the version data space.

6. The method according to claim 1, wherein Obtaining snapshot data corresponding to a historical version of a target object from the object version snapshot table, and determining original structure data of the historical version of the target object based on the snapshot data, including: Obtaining first information or second information of a historical version of the target object, wherein the first information includes an object ID and a version number of the historical version of the target object, and the second information includes a data fingerprint of the historical version of the target object; querying snapshot data corresponding to the first information or the second information from the object version snapshot table; Decoding the snapshot data corresponding to the first information or the second information to obtain serialized data of the historical version of the object to be loaded; A deserialization operation is performed on the serialized data of the historical version of the object to be loaded to obtain the original structure data of the historical version of the target object.

7. The method according to claim 6, characterized in that Obtaining the first information or the second information of the historical version of the target object includes: Obtaining an object ID of a target object, wherein the object ID of the target object is an object ID of any object in the historical evolution process of the project; All historical version information corresponding to the object ID is queried from the object version snapshot table, wherein the historical version information includes the version number of the target object historical version and the snapshot data fingerprint of the target object historical version.

8. The method according to claim 1, characterized in that Determine the object index list of the target project version, including: Obtaining a target project historical version number, wherein the target project historical version number is a version number in any row of data in the project version information table; Query the object index snapshot data fingerprint corresponding to the historical version number of the target project from the project version information table; Querying the object index snapshot data corresponding to the object index snapshot data fingerprint from the object index snapshot; The object index snapshot data is decoded to obtain an object index list of the historical version of the target project.

9. A version processing device for structured object data, characterized in that: include: a determination module, configured to determine a version data space storing historical version data of structured object data, wherein the version data space stores at least an object version snapshot table, an object index snapshot table, and a project version information table, wherein the object version snapshot table is configured to store object version snapshot information of each version of each object, the object index snapshot table is configured to store index snapshot information of all structured object data of each version of a project, and the project version information table is configured to store version submission information corresponding to each version of the project; A first generating module is configured to generate new version data of any structured object data, and write the new version data of the structured object data into the version data space; a second generating module, configured to generate new version data of the entire project, and write the new version data of the entire project into the version data space, wherein the new version data of the entire project is composed of the new version data of the structured object data; A first determining module is configured to obtain snapshot data corresponding to a historical version of a target object from the object version snapshot table, and determine original structure data of the historical version of the target object based on the snapshot data; The second determining module is used to determine the object index snapshot data fingerprint corresponding to the target project historical version from the object index snapshot table and the project version information table, and determine the object index list of the target project version based on the object index snapshot data fingerprint.

10. An electronic device, characterized in that: include: a memory for storing program instructions; The processor is connected to the memory and is used to execute program instructions that implement the following functions: determining a version data space for storing historical version data of structured object data, wherein the version data space stores at least an object version snapshot table, an object index snapshot table, and a project version information table, the object version snapshot table being used to store object version snapshot information of each version of each object, the object index snapshot table being used to store index snapshot information of all structured object data of each version of a project, and the project version information table being used to store version submission information corresponding to each version of a project; generating new version data of any structured object data and writing the new version data of the structured object data into the version data space; generating new version data of the entire project and writing the new version data of the entire project into the version data space, wherein the new version data of the entire project consists of the new version data of the structured object data; obtaining snapshot data corresponding to a historical version of a target object from the object version snapshot table, and determining original structure data of the historical version of the target object based on the snapshot data; determining an object index snapshot data fingerprint corresponding to the historical version of the target project from the object index snapshot table and the project version information table, and determining an object index list of the target project version based on the object index snapshot data fingerprint.

11. A non-volatile storage medium, characterized in that: The non-volatile storage medium includes a stored program, wherein when the program is executed, the device where the non-volatile storage medium is located is controlled to execute the version processing method for structured object data according to any one of claims 1 to 8.

Images