Data version management method, device and equipment and storage medium
By reading and executing the registration information and change dataset of transaction entity groups, the problem that time-series historical models cannot support transaction rollback is solved, and data version management is simplified and its efficiency is improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- KINGDEE SOFTWARE(CHINA) CO LTD
- Filing Date
- 2022-08-02
- Publication Date
- 2026-07-21
AI Technical Summary
Existing time-series historical models cannot support transaction rollback operations, leading to complex data version management.
By responding to the transaction rollback command, the system reads the registration information of the target transaction entity group, obtains the transaction change dataset, and performs the rollback operation based on the state before the change, thus supporting transaction rollback.
It enables the undoability of transaction operations, simplifies the control of data version management, and improves management efficiency.
Smart Images
Figure CN115344553B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a data version management method, apparatus, device and storage medium. Background Technology
[0002] Time-series historical models include linear and non-linear time-series historical models. A linear time-series historical model is a data version management model with continuous time chain constraints on the data history within a business object. Each change requires specifying the effective date of the business data, and the corresponding data version needs to be referenced at different time periods. A non-linear time-series historical model is a data version management model for the data history within a business object that does not have continuous time chain constraints. Each change only requires specifying the operation date, and the latest data version can be used at different time periods.
[0003] Currently, time-series historical models can archive data versions and record transactions, but they cannot support transaction rollback operations. This makes it impossible to roll back user errors in some operational scenarios, thus complicating data version management. Summary of the Invention
[0004] This application provides a data version management method, apparatus, device, and storage medium to solve the technical problem that the current time-series historical model cannot support transaction rollback operations.
[0005] To address the aforementioned technical problems, firstly, this application provides a data version management method, comprising:
[0006] In response to the transaction rollback command for the target data, the registration information of the target transaction entity group is read. The target transaction entity group is the transaction entity group registered with the historical model. The historical model is used to manage the data version of the target data.
[0007] If the registration information indicates that the entity has already registered, then obtain the transaction change dataset for the target transaction entity group.
[0008] From the transaction change dataset, filter the list of target transaction change versions that correspond to the target data. The list of target transaction change versions includes the state of the target data before the change.
[0009] Based on the state before the change, perform the undo change operation corresponding to the target data.
[0010] In some implementations of the first aspect, based on the state before the change, the target data is undoed, including:
[0011] If the change reversal operation is a partial reversal operation, then the state before the change is modified to a partially reversal state, and the target data is reversed based on the state before the change, and the state before the change is modified to a partially reversal state. The scope of the reversal of the target data is also recorded in the target transaction change version list.
[0012] If the undo change operation is not a partial undo operation, then based on the state before the change, the target data is undone, the state before the change is changed to the undone state, and the scope of the undoing of the target data is recorded in the target transaction change version list.
[0013] In some implementations of the first aspect, the target data is revoked based on its state before the change, including:
[0014] If the state before the change was not empty or was a temporary version state, then restore the target data;
[0015] If the previous state was empty or a temporary version, the target data will be discarded.
[0016] In some implementations of the first aspect, the target data is recovered, including:
[0017] If the target data is archived data, then the state before the change will be used to overwrite the state after the change.
[0018] If the data type of the target data is valid, then the time before the change corresponding to the state before the change will be used to overwrite the time after the change of the target data. The time before the change and the time after the change belong to the version effective time or version expiration time of the target data.
[0019] Among some implementations of the first aspect, the methods also include:
[0020] Retrieve the new version of the data corresponding to the existing data;
[0021] The validity of the new version data is determined based on the first version time of the new version data and the second version time of the original data.
[0022] If the new version data is valid, then the new version data will be saved as the target data, and the transaction change version list of the transaction entity group will be updated to obtain the target transaction change version list.
[0023] In some implementations of the first aspect, the validity of the new version data is determined based on the first version time of the new version data and the second version time of the original data, including:
[0024] If the new version data does not take effect immediately, and the time relationship between the first version time and the second version time satisfies the first preset time relationship, then the new version data is determined to be valid temporary version data;
[0025] If the new version data takes effect immediately and the time relationship satisfies the second preset time relationship, then the new version data is determined to be valid data.
[0026] In some implementations of the first aspect, after determining the validity of the new version data based on the first version time of the new version data and the second version time of the original data, the following are also included:
[0027] If the new version data takes effect immediately, and the time relationship between the first version time and the second version time does not meet the second preset time relationship, then the original data will be modified according to the time relationship.
[0028] Secondly, this application also provides a data version management device, comprising:
[0029] The read module is used to read the registration information of the target transaction entity group in response to the transaction rollback command of the target data. The target transaction entity group is the transaction entity group registered in the historical model. The historical model is used to manage the data version of the target data.
[0030] The acquisition module is used to acquire the transaction change dataset of the target transaction entity group if the registration information indicates that it has been registered.
[0031] The filtering module is used to filter the target transaction change version list from the transaction change dataset, which includes the state of the target data before the change.
[0032] The execution module is used to perform the undo change operation corresponding to the target data based on the state before the change.
[0033] Thirdly, this application also provides a computer device, including a processor and a memory, wherein the memory is used to store a computer program, and the computer program, when executed by the processor, implements the data version management method as described in the first aspect.
[0034] Fourthly, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the data version management method as described in the first aspect.
[0035] Fifthly, this application also provides a computer program product that, when run on a computer device, enables the computer device to implement the data version management method of the first aspect.
[0036] Compared with the prior art, this application has the following beneficial effects:
[0037] This application, in response to a transaction rollback command for the target data, reads the registration information of the target transaction entity group to enable the use of historical models for data version management of the target data based on the registration information. If the registration information indicates that the data is already registered, the application obtains the transaction change dataset of the target transaction entity group and filters the target transaction change version list corresponding to the target data from the transaction change dataset to obtain the pre-change state of the target data, which serves as the data basis for subsequent rollback operations, thereby supporting transaction rollback operations. Based on the pre-change state, the application then executes the corresponding rollback operation for the target data, ensuring the unchangeability of transaction operations and eliminating the need to manually restore the pre-change data version, thus simplifying the management and control of data versions and improving management and control efficiency. Attached Figure Description
[0038] Figure 1 This is a schematic flowchart illustrating a data version management method according to an embodiment of this application;
[0039] Figure 2 This is a schematic diagram illustrating the registration process of a transaction entity group as shown in an embodiment of this application;
[0040] Figure 3 This is a schematic diagram of registration information shown in an embodiment of this application;
[0041] Figure 4 This is a schematic diagram illustrating the relationship between historical related tables in the historical model database, as shown in an embodiment of this application.
[0042] Figure 5 This is a schematic diagram illustrating the state transition relationship of historical data versions in an embodiment of this application;
[0043] Figure 6 This is a flowchart illustrating a data version management method according to another embodiment of this application;
[0044] Figure 7 This is a flowchart illustrating a data version management method according to another embodiment of this application;
[0045] Figure 8 This is a schematic diagram illustrating the data version change process in an embodiment of this application;
[0046] Figure 9 This is a schematic diagram of the structure of a data version management device shown in an embodiment of this application;
[0047] Figure 10 This is a schematic diagram of the structure of a computer device shown in an embodiment of this application. Detailed Implementation
[0048] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.
[0049] The embodiments of this application can be applied to various enterprise resource planning (ERP) systems, including but not limited to production management systems, supply chain systems, human resources systems, financial systems, tax systems, and auditing systems.
[0050] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating a data version management method provided in an embodiment of this application. The data version management method of this application can be applied to computer devices, including but not limited to smartphones, laptops, tablets, desktop computers, physical servers, and cloud servers. Figure 1 As shown, the data version management method of this embodiment includes steps S101 to S104, which are described in detail below:
[0051] Step S101: In response to the transaction rollback instruction for the target data, read the registration information of the target transaction entity group. The target transaction entity group is a transaction entity group registered with the historical model. The historical model is used to manage the data version of the target data.
[0052] In this step, the transaction rollback instruction is an instruction to initiate a rollback operation on the target data. The transaction entity group is a group of transactions that register historical models, enabling computer applications to use historical models for data version management. This includes, but is not limited to, transaction table entities, business transaction relationship entities, and historical version transaction relationship entities, which can be obtained through entity registration or application registration. When an entity is not registered with a transaction entity group, it is allowed to use the historical model registered by the application to which it belongs; when an application is not registered with a transaction entity group, the application is not allowed to use the historical model.
[0053] Optionally, the registration information is the registration information obtained after entity registration or application registration. For example, such as... Figure 2The diagram illustrates the registration process for transaction entity groups. The application sends a request to the middleware platform to register the historical model. The middleware platform creates the transaction entity group and related historical tables, writes the registration information to the database, and returns the API (interface) for calling the historical model. When performing transaction processing (such as transaction rollback), the application calls the historical model to the middleware platform through this API. The middleware platform sends a request to the database to verify the registration information. After verification, the database returns the verification result to the middleware platform to continue operations such as obtaining the target transaction change version list of the transaction entity group.
[0054] Optionally, such as Figure 3 The diagram illustrates the registration information. During application registration, the application's private transaction-related tables are registered. During entity registration, the private transaction-related tables, personalized historical processing classes, and historical model parameter configurations are registered. Transaction-related tables include, but are not limited to, the application historical model registry, the transaction entity group table, and the entity historical model registry. Transaction entity groups are associated with both the application historical model registry and the entity historical model registry, enabling transaction entities within the transaction entity group to use the corresponding historical model, thereby facilitating data version management of the target data.
[0055] Historical models include, but are not limited to, linear time-series historical models and nonlinear time-series historical models. For example... Figure 4 The diagram illustrates the relationships between historical tables in the historical model database. These tables include business tables, transaction tables, business transaction relationship tables, historical version transaction relationship tables, and a transaction change version list. The transaction change version list describes transaction change operations on the target data and includes, but is not limited to, the transaction tables and historical version transaction tables. The transaction tables include transaction status (e.g., not executed, executed, rolled back, or partially rolled back), transaction type (e.g., business and rolled back), transaction execution method (e.g., manual execution and automatic execution), transaction batch type (e.g., single, batch atomic, and batch non-atomic; batch atomic means the transaction operation complies with atomicity), and transaction ID (e.g., rolled-back transaction ID). The historical version transaction tables include the state before the change (e.g., temporarily stored, pending effect, in effect, expired, deleted, and obsolete).
[0056] It should be noted that the transaction-related table serves as the credential for calling the historical model (specifically, the historical related table) for data version management, while the historical related table serves as the data and operation records during the execution of the change operation, so that the change operation can be reversed later based on these data and operation records.
[0057] The historical model in this application embodiment does not include business data, thus isolating transaction data from business data. It also uses transaction entity groups to aggregate and separate transaction data during subsequent transaction operations, thereby eliminating the need to focus on the underlying logic of the historical model and improving the subsequent development efficiency and application effect of the historical model.
[0058] Step S102: If the registration information indicates that the entity has been registered, then obtain the transaction change dataset of the target transaction entity group.
[0059] In this step, the presence of registration information indicates that registration has been completed. Registration information includes at least one of entity registration information and application registration information. If entity registration information is found, it means the entity registration information is complete, and historical models can be accessed. If no entity registration information is found, the system continues reading application registration information. If application registration information is found, it means the application registration information is complete, and historical models can be accessed. If no application registration information is found, historical models cannot be accessed.
[0060] The transaction change dataset is a collection of historical related tables corresponding to the target transaction entity group, including but not limited to business tables, transaction tables, business transaction relationship tables, historical version transaction relationship tables, and transaction change version lists related to the target transaction entity group.
[0061] Understandably, after the target transaction entity group, the historical model can be directly invoked, and the transaction change dataset related to the target transaction entity group can be obtained from the historical model.
[0062] Step S103: From the transaction change dataset, filter the target transaction change version list corresponding to the target data. The target transaction change version list includes the state of the target data before the change.
[0063] In this step, the "pre-change state" refers to the data state of the target data before the change, which includes, but is not limited to, pending, in effect, expired, deleted, and obsolete. For valid data, this means data that was valid in the past, present, and future, with states of pending, in effect, and expired, respectively. For archived data, this means data that has been changed and the old version is no longer valid, with a state of deleted. For obsolete data, this means a new data version was generated by a transaction, and when that transaction is rolled back, the newly generated data version is no longer available, with a state of obsolete.
[0064] Optionally, to facilitate querying the target transaction change version list related to the target data, a unique identifier (such as an identifier ID) is assigned to the target data, and the identifier ID is recorded in the target transaction change version list. This facilitates subsequent querying of the target transaction change version list related to the target data based on the identifier ID, and also facilitates establishing an association with the transaction ID of each transaction change operation.
[0065] Step S104: Based on the state before the change, perform the undo change operation corresponding to the target data.
[0066] In this step, historical tables enable the historical model to support transaction recording at the operation level (such as the state before the change), leaving a trail of data operations, and also supporting partial undoing of a single operation. Optionally, such as Figure 5 The diagram illustrates the state transitions of historical data versions. Data states can be changed by adjusting the effective and expiration times of data versions, and changes can also be reversed using the "Undo Change" operation. It should be noted that... Figure 5 In Chinese, “<=” means less than or equal to.
[0067] exist Figure 1 Based on the illustrated embodiment, Figure 6 A flowchart illustrating a data version management method provided in another embodiment is shown. For example... Figure 6 As shown, with Figure 1 The same steps will not be repeated here. Step S104 includes:
[0068] Step S601: If the undo change operation is a partial undo operation, then according to the state before the change, the target data is undone, the state before the change is modified to a partial undo state, and the scope of the undo of the target data is recorded in the target transaction change version list.
[0069] Step S602: If the revocation change operation is not a partial revocation operation, then according to the state before the change, the target data is revoked, the state before the change is modified to the revoked state, and the revocation range of the target data is recorded in the target transaction change version list.
[0070] In this embodiment, since in some scenarios only a portion of the target data needs to be revoked—for example, if the target data is "apple is a fruit," and only "apple" needs to be revoked back to "mango"—a partial revocation operation is selected. Optionally, the revocation operation corresponds to the data to be revoked in the target data (i.e., the revocation range). If the data to be revoked is the complete target data, the revocation operation is not a partial revocation operation; if the data to be revoked is a portion of the target data, the revocation operation is a partial revocation operation. The partial revocation status indicates that some data in the target data has been revoked, and the revoked status indicates that all target data has been revoked.
[0071] Optionally, the step of revoking the target data based on the state before the change in steps S601 and S602 includes:
[0072] If the state before the change is not empty or a temporary version state, then the target data is restored;
[0073] If the state before the change is empty or in a temporary version state, then the target data is discarded.
[0074] In this embodiment, a null value indicates that the target data did not exist before the change, meaning the target data is the new version data. A temporary version status indicates that the target data was temporarily stored version data before the change. For example... Figure 5 As shown, when the state before the change is empty or a temporary version, it means that the target data did not exist before the change or belonged to a temporary version of data. Therefore, the change cancellation operation is performed, which is equivalent to discarding the current data. When the state before the change is not empty or a temporary version, it means that the target data belonged to a saved version of data before the change. Therefore, based on the state before the change, the target data is restored to the state before the change.
[0075] Optionally, the recovery of the target data includes:
[0076] If the data type of the target data is archived data, then the state before the change is used to overwrite the state after the change of the target data;
[0077] If the data type of the target data is valid data, then the time before the change corresponding to the state before the change is used to cover the time after the change of the target data. The time before the change and the time after the change belong to the version effective time or version expiration time of the target data.
[0078] In this embodiment, since the archived data renders the old version data invalid, the state before the change is overwritten to restore the target data. Valid data, on the other hand, has its effective time or expiration time changed; therefore, the effective time of the previous version is used to overwrite the effective time of the new version, or the expiration time of the previous version is used to overwrite the expiration time of the new version.
[0079] This application embodiment uses the data status and data type of the target data to perform targeted undo / change operations on the target data, enabling the historical model to support transaction undo operations, meeting the user's need to undo transactions in certain scenarios, and improving the user experience.
[0080] In some embodiments, Figure 1 Based on the illustrated embodiment, Figure 7 A flowchart illustrating a data version management method according to yet another embodiment is shown. For example... Figure 7 As shown, with Figure 1 The same steps will not be repeated here. Before step S103, the method further includes:
[0081] Step S701: Obtain the new version data corresponding to the original data;
[0082] Step S702: Determine the validity of the new version data based on the first version time of the new version data and the second version time of the original data;
[0083] Step S703: If the new version data is valid data, then the new version data is saved as the target data, and the transaction change version list of the transaction entity group is updated to obtain the target transaction change version list.
[0084] In this embodiment, the original data refers to the data before the target data is modified. In one possible implementation, the new version data is a temporary version data, that is, a temporary version data is added on the basis of the original data, and its effective time (or expiration time) does not overlap with the original data. In another possible implementation, the new version data is newly added version data or version data after modifying the original data.
[0085] In some embodiments, Figure 7 Based on the illustrated embodiment, Figure 8 A schematic diagram illustrating the data version change process provided in an embodiment of this application is shown. For example... Figure 8 As shown, the data version changes include:
[0086] If the new version data does not take effect immediately, and the time relationship between the first version time and the second version time satisfies the first preset time relationship, then the new version data is determined to be valid temporary version data, and the temporary version data is saved.
[0087] If the new version data takes effect immediately and the time relationship satisfies the second preset time relationship, then the new version data is determined to be valid data and the valid data is saved.
[0088] If the new version data takes effect immediately, and the time relationship between the first version time and the second version time does not satisfy the second preset time relationship, then according to the time relationship, the original data is modified according to the time relationship.
[0089] In this embodiment, the new version data is determined to take effect immediately based on the "whether to take effect immediately" parameter transmitted by the interface.
[0090] When the new version data does not take effect immediately, and the intersection of the new version data's generation and expiration dates (i.e., including the generation or expiration time) between NEW[S,E] and TEMP_ALL[S,E] is the preset interval. This indicates that the new version data is temporary version data, and TEMP_ALL[S, E] is the union interval of the birth and expiration dates of all the original temporary version data.
[0091] The new version data will take effect immediately:
[0092] (1) If NEW[S, E] and OLD_ALL[S, E] are not consecutive, an error message is returned. OLD_ALL[S, E] is the union interval of the birth and expiration dates of all existing valid version data.
[0093] (2) When NEW[S, E] and OLD_ALL[S, E] are consecutive, and when the intersection between NEW[S, E] and OLD_ALL[S, E] is a preset interval. This indicates that the new version data is valid.
[0094] (3) When NEW[S,E] and OLD_ALL[S,E] are continuous, and the intersection between NEW[S,E] and OLD_ALL[S,E] is not a preset interval. When NEW[S, E] is reached, the existing valid data that intersects with NEW[S, E] is taken sequentially, and the relationship between NEW[S, E] and OLD[S, E] is determined. OLD[S, E] is the union interval of the birth and expiration dates of the existing valid data. When NEW[S, E] = OLD[S, E], it means that the new version data is valid data, and the original version data (i.e., the existing data) is deleted; when OLD[S, E] truly contains NEW[S, E], it means that the new version data is valid data, and if the time period of the data in the original version data that is covered by the new version data is in the middle of the time period of the original version data, then the original version data is split into two valid data, otherwise... Figure 3 The method shown adjusts the birth and expiration dates of the original version data. When NEW[S,E] truly contains OLD[S,E], it indicates that the new version data is valid. If the time period of the original version data is completely covered by the new version data, the original version data is deleted. When NEW[S,E] and OLD[S,E] do not contain each other and have an intersection, it indicates that the new version data is valid, and the birth and expiration dates of the original version data are adjusted.
[0095] Finally, the new version data is saved as the target data, and the transaction change version list of the transaction entity group is updated to obtain the target transaction change version list. For other embodiments that do not conform to the preset time relationship, please refer to... Figure 8 The process description will not be repeated here.
[0096] It should be noted that this embodiment records multiple transaction change scenarios through a target transaction change version list, so that the historical model can perform transaction rollback for multiple transaction change scenarios, thereby meeting the transaction rollback requirements under various transaction change scenarios and making the application more widely applicable.
[0097] To implement the data version management method corresponding to the above method embodiments, and to achieve the corresponding functions and technical effects. See also Figure 9 ,Figure 9 This diagram illustrates a structural block diagram of a data version management device according to an embodiment of this application. For ease of explanation, only the parts relevant to this embodiment are shown. The data version management device provided in this embodiment includes:
[0098] The reading module 901 is used to read the registration information of the target transaction entity group in response to the transaction rollback command of the target data. The target transaction entity group is a transaction entity group registered in the historical model. The historical model is used to manage the data version of the target data.
[0099] The acquisition module 902 is used to acquire the transaction change dataset of the target transaction entity group if the registration information indicates that it has been registered.
[0100] The filtering module 903 is used to filter a list of target transaction change versions corresponding to the target data from the transaction change dataset. The list of target transaction change versions includes the state of the target data before the change.
[0101] The execution module 904 is used to perform the undo change operation corresponding to the target data based on the state before the change.
[0102] In some embodiments, the execution module 904 includes:
[0103] The first cancellation unit is used to cancel the target data according to the state before the change if the cancellation change operation is a partial cancellation operation, and modify the state before the change to a partially cancelled state, and record the cancellation range of the target data in the target transaction change version list.
[0104] The second cancellation unit is used to cancel the target data according to the state before the change if the cancellation change operation is not a partial cancellation operation, and to modify the state before the change to a cancelled state, and to record the cancellation range of the target data in the target transaction change version list.
[0105] In some embodiments, the step of revoking the target data based on the state before the change in the first revocation unit and the second revocation unit includes:
[0106] If the state before the change is not empty or a temporary version state, then the target data is restored;
[0107] If the state before the change is empty or in a temporary version state, then the target data is discarded.
[0108] In some embodiments, restoring the target data includes:
[0109] If the data type of the target data is archived data, then the state before the change is used to overwrite the state after the change of the target data;
[0110] If the data type of the target data is valid data, then the time before the change corresponding to the state before the change is used to cover the time after the change of the target data. The time before the change and the time after the change belong to the version effective time or version expiration time of the target data.
[0111] In some embodiments, the method further includes:
[0112] The second acquisition module is used to acquire the new version data corresponding to the original data;
[0113] The determination module is used to determine the validity of the new version data based on the first version time of the new version data and the second version time of the original data;
[0114] The first change module is used to save the new version data as the target data if the new version data is valid, and update the transaction change version list of the transaction entity group to obtain the target transaction change version list.
[0115] In some embodiments, the determining module includes:
[0116] The first determination unit is used to determine that the new version data is valid temporary version data if the new version data does not take effect immediately and the time relationship between the first version time and the second version time satisfies the first preset time relationship.
[0117] The second determination unit is used to determine that the new version data is valid data if the new version data takes effect immediately and the time relationship satisfies the second preset time relationship.
[0118] In some embodiments, the method further includes:
[0119] The second modification module is used to perform a modification operation on the original data corresponding to the time relationship if the new version data takes effect immediately and the time relationship between the first version time and the second version time does not meet the second preset time relationship.
[0120] The data version management device described above can implement the data version management method of the above method embodiments. The options in the above method embodiments are also applicable to this embodiment, and will not be detailed here. The remaining content of this application embodiment can be referred to the content of the above method embodiments, and will not be repeated in this embodiment.
[0121] Figure 10This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 10 As shown, the computer device 100 of this embodiment includes: at least one processor 1000 ( Figure 10 (Only one is shown) a processor, a memory 1001, and a computer program 1002 stored in the memory 1001 and executable on the at least one processor 1000, wherein the processor 1000 executes the computer program 1002 to implement the steps in any of the above method embodiments.
[0122] The computer device 100 may be a smartphone, tablet computer, desktop computer, cloud server, or other computing device. This computer device may include, but is not limited to, a processor 1000 and a memory 1001. Those skilled in the art will understand that... Figure 10 The computer device 100 is merely an example and does not constitute a limitation on the computer device 100. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.
[0123] The processor 1000 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.
[0124] In some embodiments, the memory 1001 may be an internal storage unit of the computer device 100, such as a hard disk or memory of the computer device 100. In other embodiments, the memory 1001 may be an external storage device of the computer device 100, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 100. Further, the memory 1001 may include both internal and external storage units of the computer device 100. The memory 1001 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 1001 can also be used to temporarily store data that has been output or will be output.
[0125] In addition, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above method embodiments.
[0126] This application provides a computer program product that, when run on a computer device, enables the computer device to execute the steps described in the various method embodiments above.
[0127] In the several embodiments provided in this application, it will be understood that each block in the flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the figures. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved.
[0128] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0129] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application for those skilled in the art.
Claims
1. A data version management method, characterized in that, include: In response to a transaction rollback command for the target data, the registration information of the target transaction entity group is read. The target transaction entity group is a transaction entity group registered with a historical model, and the historical model is used to manage the data version of the target data. If the registration information indicates that registration has been completed, then obtain the transaction change dataset of the target transaction entity group; From the transaction change dataset, filter the target transaction change version list corresponding to the target data, the target transaction change version list includes the state of the target data before the change; Based on the state before the change, execute the undo change operation corresponding to the target data; The step of performing the undo change operation on the target data based on the state before the change includes: If the undo change operation is a partial undo operation, then according to the state before the change, the target data is undone, the state before the change is modified to a partially undone state, and the scope of the undoing of the target data is recorded in the target transaction change version list; The cancellation operation corresponds to the data to be cancelled in the target data. If the data to be cancelled is the complete data of the target data, the cancellation operation is not a partial cancellation operation. If the data to be cancelled is a part of the target data, the cancellation operation is a partial cancellation operation.
2. The data version management method as described in claim 1, characterized in that, The step of performing the undo change operation on the target data based on the state before the change further includes: If the reversal operation is not a partial reversal operation, then based on the state before the change, the target data is reversed, the state before the change is modified to a reversed state, and the reversal scope of the target data is recorded in the target transaction change version list.
3. The data version management method as described in claim 2, characterized in that, The step of revoking the target data based on the state before the change includes: If the state before the change is not empty or a temporary version state, then the target data is restored; If the state before the change is empty or in a temporary version state, then the target data is discarded.
4. The data version management method as described in claim 3, characterized in that, The recovery of the target data includes: If the data type of the target data is archived data, then the state before the change is used to overwrite the state after the change of the target data; If the data type of the target data is valid data, then the time before the change corresponding to the state before the change is used to cover the time after the change of the target data. The time before the change and the time after the change belong to the version effective time or version expiration time of the target data.
5. The data version management method as described in claim 1, characterized in that, The method further includes: Retrieve the new version of the data corresponding to the existing data; The validity of the new version data is determined based on the first version time of the new version data and the second version time of the original data; If the new version data is valid, then the new version data is saved as the target data, and the transaction change version list of the transaction entity group is updated to obtain the target transaction change version list.
6. The data version management method as described in claim 5, characterized in that, The step of determining the validity of the new version data based on the first version time of the new version data and the second version time of the original data includes: If the new version data does not take effect immediately, and the time relationship between the first version time and the second version time satisfies the first preset time relationship, then the new version data is determined to be valid temporary version data. If the new version data takes effect immediately and the time relationship satisfies the second preset time relationship, then the new version data is determined to be valid data.
7. The data version management method as described in claim 5, characterized in that, After determining the validity of the new version data based on the first version time of the new version data and the second version time of the original data, the method further includes: If the new version data takes effect immediately, and the time relationship between the first version time and the second version time does not satisfy the second preset time relationship, then according to the time relationship, the original data is modified according to the time relationship.
8. A data version management device, characterized in that, include: The reading module is used to read the registration information of the target transaction entity group in response to the transaction rollback command of the target data. The target transaction entity group is a transaction entity group registered in the historical model. The historical model is used to manage the data version of the target data. The acquisition module is used to acquire the transaction change dataset of the target transaction entity group if the registration information indicates that it has been registered. The filtering module is used to filter a list of target transaction change versions corresponding to the target data from the transaction change dataset. The list of target transaction change versions includes the state of the target data before the change. The execution module is used to perform the undo change operation corresponding to the target data based on the state before the change; The step of performing the undo change operation on the target data based on the state before the change includes: If the undo change operation is a partial undo operation, then according to the state before the change, the target data is undone, the state before the change is modified to a partially undone state, and the scope of the undoing of the target data is recorded in the target transaction change version list; The cancellation operation corresponds to the data to be cancelled in the target data. If the data to be cancelled is the complete data of the target data, the cancellation operation is not a partial cancellation operation. If the data to be cancelled is a part of the target data, the cancellation operation is a partial cancellation operation.
9. A computer device, characterized in that, It includes a processor and a memory, the memory being used to store a computer program, which, when executed by the processor, implements the data version management method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the data version management method as described in any one of claims 1 to 7.
11. A computer program product, when run on a computer device, causes the computer device to implement the data version management method as described in any one of claims 1 to 7.