Recording method and system for change history of lightweight business data

Abstract

The invention relates to the technical field of data management, and provides a lightweight business data change history recording method and system.The method comprises the steps that data persistence operation initiated through an ORM framework is intercepted and analyzed, and the operation type, involved target business objects and corresponding operation conditions of the data persistence operation are determined; reading external dynamic configuration, and judging whether the target business object is set as an audit object which needs to record a change history according to configuration information; and for the audit object needing to record the change history, automatically executing data state capture and audit log generation corresponding to the operation type. According to the method, the development efficiency can be remarkably improved, the maintenance cost can be remarkably reduced, non-invasion and purity of service codes are achieved, high flexibility and expandability are provided, integrity and traceability of audit data are guaranteed, and system operation and maintenance and data governance experience are optimized.

Description

Technical Field

[0001] This invention relates to the field of data management technology, and in particular to a method and system for recording the history of lightweight business data changes. Background Technology

[0002] In the development and operation of various enterprise business systems (such as ERP, CRM, SCM, etc.), tracking and auditing the change history of core business data is a common and critical requirement. For example, any modification, creation, or deletion of important business documents such as order status, customer information, inventory quantity, and contract terms needs to be clearly recorded and traceable to meet business and management requirements such as internal control, compliance audit, problem investigation, and operation review.

[0003] Currently, the mainstream approach to implementing a business data change history is to hard-code it at the business logic layer. Developers explicitly write code to record data changes in service methods that implement business functions (such as saving orders or updating customer information). This recording typically includes: querying or saving the old state of the data before performing database operations, retrieving the new state of the data after performing database operations, and then writing the comparison results before and after the change, the operator, the operation time, and other information into a separate "operation log table" or "audit table".

[0004] However, this traditional implementation method has the following drawbacks and limitations: 1. Highly intrusive code, compromising the purity of business logic: Audit logic is highly coupled with core business logic. Business methods are filled with a large amount of non-functional logging code unrelated to core business processes, severely reducing code readability and maintainability. The core goal of business code should be to correctly complete business operations, not to record its own changes. This intrusive design violates the software design principle of separation of concerns.

[0005] 2. Low development efficiency and prone to errors and omissions: Each business module requiring auditing needs to repeatedly write logging code with similar structures but different details. This not only increases the development workload significantly but also leads to high maintenance costs due to code duplication. When developers are negligent, they are very likely to omit audit logic in new features or forget to update the corresponding audit code when modifying business logic, resulting in incomplete or incorrect audit records and posing risks to subsequent traceability and auditing.

[0006] 3. Poor system scalability and flexibility: The audit logic is tightly coupled with specific business functions, making it extremely difficult to enable, disable, or adjust these functions. If a business module no longer requires auditing, or if the audit strategy needs to be changed (e.g., only recording changes to specific fields), the source code must be modified, and a series of processes including retesting and deployment must be completed. This strong coupling makes it difficult for the system to quickly respond to dynamic changes in business rules or compliance requirements.

[0007] 4. Potential inconsistencies and performance issues: Manually managing the writing of audit records within business methods requires extra attention to transaction consistency. If saving audit records fails, should the main business operation be rolled back, or should the data inconsistency be allowed to continue? Furthermore, frequent additional queries (to retrieve old data) and inserts (to save logs), if poorly designed, may have a noticeable impact on the performance of the original business operations.

[0008] Chinese patent CN107644107A discloses a method and related apparatus for generating internal audit logs. This solution utilizes data state snapshots naturally generated during data persistence by an ORM framework. By comparing the differences between these snapshots, it reverse-engineers and records changes in business data, aiming to supplement the shortcomings of traditional operation logs that cannot record specific data content changes. However, in practical applications, this solution has the following shortcomings: 1. Its difference analysis relies on the "dirty flag" marked by the ORM engine on changed data, meaning its auditing capabilities are deeply coupled with the implementation of a specific ORM framework. If the ORM framework's dirty checking mechanism is imperfect, or if dirty checking is not triggered in certain operational scenarios (such as directly executing native SQL or batch updates), this auditing solution will fail, leading to missed records. 2. There are blind spots in data capture timing; the ORM's dirty checking mechanism alone cannot automatically capture the complete state of deleted data before deletion, posing a risk of incomplete recording. 2. The solution supports configuring audit fields, but to achieve discrepancy analysis, it is still necessary to maintain a complete state snapshot of the objects involved in the operation (at least a snapshot of the configured fields) in memory. For complex business objects with many fields and large amounts of data, continuously maintaining and comparing multiple complete state snapshots may lead to significant memory overhead and CPU computation costs, impacting system performance. 3. Although the audit logic is processed at the ORM layer, the solution mentions that the configuration needs to be "integrated into the functional attributes of the fields" or "set during development." The configuration behavior may still need to be embedded in or associated with the definition of the business entity model, failing to achieve complete management of audit rules through an externalized, centralized configuration method, which still has some impact on the purity of the business code.

[0009] Therefore, how to provide an automated, non-intrusive, flexibly configurable, and easy-to-maintain solution that separates data change auditing from complex business code and provides it as a unified system-level infrastructure, so that developers can focus more on the business logic itself, while providing powerful and reliable data traceability capabilities for system operation and maintenance, has become an urgent technical problem to be solved. Summary of the Invention

[0010] In view of this, in order to overcome the shortcomings of the prior art, the present invention aims to provide a lightweight method and system for recording business data change history.

[0011] According to a first aspect of the present invention, a method for recording lightweight business data change history is provided, the method comprising: Step S1: Intercept and parse the data persistence operation initiated through the ORM framework to determine its operation type, the target business object involved, and the corresponding operation conditions; Step S2: Read the external dynamic configuration and determine whether the target business object is set as an audit object that needs to record change history based on the configuration information; Step S3: For audit objects that require recording change history, automatically execute data status capture and audit log generation corresponding to the operation type.

[0012] Optionally, the lightweight business data change history recording method of the present invention includes step S1, which includes: using the extension mechanism provided by the ORM framework to intercept the SQL statement before it is executed, identifying its operation type by parsing the intercepted SQL statement, mapping the target data table in the SQL operation to a specific business object entity class according to the preset entity-table mapping relationship in the ORM framework, and extracting the conditional clauses in the operation to determine the affected data range.

[0013] Optionally, the method for recording the lightweight business data change history of the present invention includes step S2, which includes: Maintain a dynamically updatable audit configuration list, which contains the fully qualified name or unique identifier of the entity class of the business object; The entity class information of the target business object is compared with the audit configuration list. If the entity class information of the target business object exists in the audit configuration list, the target business object is determined to need to be audited. If the entity class information of the target business object does not exist in the audit configuration list, it is directly allowed and the original data persistence operation is performed without any audit record.

[0014] Optionally, in the lightweight business data change history recording method of the present invention, the dynamically updatable audit configuration list in step S2 is stored in an external configuration file or configuration center, and the change notification of the audit configuration list is periodically monitored or received in real time. When the content of the list changes, all subsequent data persistence operations are audited based on the changed audit configuration list.

[0015] Optionally, the lightweight business data change history recording method of the present invention includes step S3, which includes: before and after performing the original data operation, obtaining the pre-change status data and / or post-change status data of the business object, generating an audit record containing operation context information, and persisting it to a dedicated storage.

[0016] Optionally, in the lightweight business data change history recording method of the present invention, step S3, generating an audit record containing operation context information and persisting it to a dedicated storage, includes: constructing an audit record entity object with a fixed structure, the object containing operation type, business object entity class name, business object primary key value, object state before change serialized in JSON string format, object state after change serialized in JSON string format, operator identifier, and operation timestamp field, and saving the audit record entity object to a business data audit table in the database dedicated to storing change history through an ORM framework.

[0017] Optionally, in the lightweight business data change history recording method of the present invention, in step S3, when the operation type is "add", the new SQL operation is first allowed and executed to complete the data insertion. After the insertion operation is completed, the complete business object instance that has been persisted and whose primary key has been automatically generated by the database is directly obtained from the ORM framework context. The complete status data of the business object instance is used as the changed data. Combined with the operation type, object primary key, operator, and operation time, an audit record of the new operation is generated.

[0018] Optionally, in the lightweight business data change history recording method of the present invention, in step S3, when the operation type is deletion, before executing the deletion SQL operation, a query statement is constructed based on the conditional clauses in the SQL, the query statement is executed, and the complete status data of all business object instances to be deleted is obtained as the data before the change; then the original deletion SQL operation is executed, and based on the queried data before the change, combined with the operation type, object primary key, operator, and operation time, an audit record of the deletion operation is generated for each deleted object.

[0019] Optionally, in the lightweight business data change history recording method of the present invention, in step S3, when the operation type is update, before executing the update SQL operation, a query is constructed based on the update conditions to obtain the complete status data of the business object before the update, as the data before the change; the update SQL operation is allowed and executed; after the update operation is executed, a query is constructed again based on the primary key of the business object or the update conditions to obtain the complete status data of the same business object after the update, as the data after the change; the obtained data before the change and the obtained data after the change are associated through the business primary key to generate an update operation audit record that simultaneously includes the status before and after the change, operation type, object primary key, operator, and operation time.

[0020] According to a second aspect of the present invention, a lightweight business data change history recording system is provided, the system comprising:

[0021] The operation interception and parsing module is used to intercept and parse data persistence operations initiated through the ORM framework, and determine the operation type, the target business object involved, and the corresponding operation conditions. The audit configuration matching module is used to read external dynamic configurations and determine whether the target business object is set as an audit object whose change history needs to be recorded based on the configuration information. The history module is used to automatically capture data status and generate audit logs corresponding to the operation type for audit objects that require recording change history.

[0022] The lightweight business data change history recording method and system of the present invention have the following beneficial technical effects: 1. Significantly improves development efficiency and reduces maintenance costs This fundamentally eliminates the development workload caused by manually writing audit code, and also avoids the risks of coding errors and omissions. As a system-level foundational service, its maintenance and upgrades can be performed in one place, greatly reducing long-term maintenance costs and complexity, and achieving excellent cost-effectiveness.

[0023] 2. Achieve non-intrusiveness and purity in business code. It achieves "zero intrusion" into the upper-level business code. The business logic methods focus on their core CRUD operations and business rules, without any bypass logic for logging, which greatly improves the simplicity, readability and maintainability of the business code. It also strictly follows the design principle of separation of concerns, making the software architecture clearer and more robust.

[0024] 3. Offers high flexibility and scalability It provides the system with hot-swappable auditing capabilities. Operations personnel or system administrators can dynamically add, remove, or modify the list of business objects to be audited during system runtime, based on changes in business needs or adjustments to compliance requirements. All configuration changes take effect immediately on all subsequent operations, without requiring modification of any line of business code or service interruption for redeployment. This allows the system to quickly adapt to business development needs and provides extremely high scalability.

[0025] 4. Ensure the integrity and traceability of audit data. Differentiated data capture strategies are designed for different database operation types (add, modify, delete) to ensure that business objects are fully preserved in snapshots before and / or after any change scenario. These snapshots are typically stored in a structured format (such as JSON), clearly recording all details of data changes. By combining operation type, operator, precise timestamp, and business primary key, a complete, continuous, and associative data change pipeline is formed, providing reliable and detailed data evidence for subsequent security audits, problem investigation, data recovery, and accountability.

[0026] 5. Optimize system operation and maintenance and data governance experience By consolidating scattered data change information into a standardized business update record table, front-end applications can easily query and display the time-sorted change trajectory of any business document throughout its entire lifecycle, using business entity type and document primary key. This centralized and standardized data traceability capability greatly simplifies the process of troubleshooting and maintenance, improves the transparency and efficiency of data governance, and makes the flow and evolution of business data readily apparent. Attached Figure Description

[0027] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 A flowchart illustrating the steps of a method for recording lightweight business data change history according to an exemplary embodiment 1 of the present invention; Figure 2 This is an example flowchart illustrating the execution process of a method for recording lightweight business data change history according to Exemplary Embodiment 2 of the present invention; Figure 3 This is an example architecture diagram of a lightweight business data change history recording system according to Exemplary Embodiment 3 of the present invention. Detailed Implementation

[0029] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0030] It should be noted that, in the absence of conflict, the following embodiments and features can be combined with each other; and, based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0031] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein. Example 1

[0032] Exemplary embodiment 1 of the present invention provides a method for recording the history of lightweight business data changes. Figure 1 This is a flowchart illustrating the steps of a method for recording lightweight business data change history according to an exemplary embodiment 1 of the present invention. Figure 1 As shown, the method of this embodiment is implemented in the following manner: Step S1: Intercept and parse the data persistence operation initiated through the ORM framework to determine its operation type, the target business object involved, and the corresponding operation conditions.

[0033] In this embodiment, the extension mechanism provided by the ORM framework is used to intercept SQL statements before they are executed. The operation type is identified by parsing the intercepted SQL statements. Based on the entity-table mapping relationship preset in the ORM framework, the target data table in the SQL operation is mapped to a specific business object entity class, and the conditional clauses in the operation are extracted to determine the range of affected data.

[0034] In this embodiment, ORM stands for Object-Relational Mapping. It is a programming technique used to build a bridge between the object model in object-oriented programming languages ​​and the table structure of relational databases, enabling automatic data conversion and persistence between the two. It maps a table in the database to a class in the program, each row in the table to an object instance of that class, and each column (field) in the table to an attribute of that object.

[0035] Step S2: Read the external dynamic configuration and determine whether the target business object is set as an audit object that needs to record change history based on the configuration information.

[0036] In this embodiment, an audit configuration list that can be dynamically updated is maintained. The audit configuration list uses the fully qualified name or unique identifier of the entity class of the business object as its content. The entity class information of the target business object is compared with the audit configuration list. If the entity class information of the target business object exists in the audit configuration list, it is determined that the target business object needs to be audited. If the entity class information of the target business object does not exist in the audit configuration list, it is directly allowed and the original data persistence operation is performed without any audit record.

[0037] It should be noted that the dynamically updatable audit configuration list in this embodiment is stored in an external configuration file or configuration center. It periodically listens for or receives change notifications of the audit configuration list in real time. When the content of the list changes, all subsequent data persistence operations are based on the changed audit configuration list for audit judgment.

[0038] Step S3: For audit objects that require recording change history, automatically execute data status capture and audit log generation corresponding to the operation type.

[0039] In this embodiment, before and after performing the original data operation, the pre-change state data and / or post-change state data of the business object are obtained, and an audit record containing operation context information is generated and persisted to dedicated storage. Specifically, this embodiment constructs an audit record entity object with a fixed structure. This object includes the operation type, business object entity class name, business object primary key value, pre-change object state serialized in JSON string format, post-change object state serialized in JSON string format, operator identifier, and operation timestamp fields. This audit record entity object is saved to a dedicated business data audit table in the database for storing change history through an ORM framework.

[0040] When the operation type is "new", the new SQL operation is first allowed and executed to complete the data insertion. After the insertion operation is completed, the complete business object instance that has been persisted and whose primary key has been automatically generated by the database is directly obtained from the ORM framework context. The complete status data of the business object instance is used as the changed data. Combined with the operation type, object primary key, operator, and operation time, an audit record for the new operation is generated.

[0041] When the operation type is deletion, before executing the deletion SQL operation, a query statement is constructed based on the conditional clauses in the SQL. This query statement is executed to obtain the complete status data of all business object instances that are about to be deleted, which is used as the data before the change. Then, the original deletion SQL operation is executed, and based on the data before the change obtained, combined with the operation type, object primary key, operator, and operation time, an audit record of the deletion operation is generated for each deleted object.

[0042] When the operation type is update, before executing the update SQL operation, a query is constructed based on the update conditions to obtain the complete status data of the business object before the update, which is used as the pre-change data. The update SQL operation is then allowed and executed. After the update operation is executed, a query is constructed again based on the primary key of the business object or the update conditions to obtain the complete status data of the same business object after the update, which is used as the post-change data. The obtained pre-change data and the obtained post-change data are associated through the business primary key to generate an update operation audit record that includes the status before and after the change, operation type, object primary key, operator, and operation time. Example 2

[0043] Exemplary embodiment 2 of the present invention provides a method for recording the history of lightweight business data changes. Figure 2 This is an example flowchart illustrating the execution process of a method for recording lightweight business data change history according to Exemplary Embodiment 2 of the present invention. Figure 2 As shown, the method of this embodiment is implemented in the following manner: SQL parsing: Determine the operation type and intercept and process CRUD operations. Retrieve table and condition information, and obtain the mapping information between tables and entity classes, as well as the mapping information between entity class attributes and table fields, based on the ORM framework.

[0044] Configuration Read: Reads the entity class information that needs to be audited from the dynamic configuration and matches it with the entity class information of this operation. If the match is found, the audit is triggered. The configured audit entity classes can be adjusted at any time to meet different audit scenarios.

[0045] The INSERT operation: First, the SQL is executed. If the primary key is automatically generated, it is then written back to the primary key field of the entity class. Because the object written by the ORM framework is the entity class, the object is directly recorded during the write process.

[0046] The delete operation: Before executing the SQL, it first assembles a query statement based on the deletion conditions, queries the objects to be deleted, and records the object deletion.

[0047] The update operation: Before executing the SQL, assemble the query statement according to the update conditions and query the objects to be updated; after executing the update SQL, query the updated objects again, match the objects before and after the update according to the business primary key, and record the object update.

[0048] The business update record table includes fields such as operation type, business document primary key, entity class, object information before change, object information after change, operator, and operation time. On the page, based on the corresponding entity class and business document primary key, the entire change history and operation records of the business document can be traced. Example 3

[0049] Exemplary embodiment 3 of the present invention provides a lightweight business data change history recording system. Figure 3 This is an example architecture diagram of a lightweight business data change history recording system according to Exemplary Embodiment 3 of the present invention, as shown below. Figure 3 As shown, the lightweight business data change history recording system of this embodiment includes: The operation interception and parsing module is used to intercept and parse data persistence operations initiated through the ORM framework, and determine the operation type, the target business object involved, and the corresponding operation conditions. The audit configuration matching module is used to read external dynamic configurations and determine whether the target business object is set as an audit object whose change history needs to be recorded based on the configuration information. The history module is used to automatically capture data status and generate audit logs corresponding to the operation type for audit objects that require recording change history.

[0050] The lightweight business data change history recording method and system of the present invention, based on the data persistence layer interception and dynamic configuration of the business data change history automatic recording mechanism, has the following beneficial technical effects: 1. Significantly improves development efficiency and reduces maintenance costs The data change auditing function is decoupled from the business logic layer and encapsulated as a general infrastructure within the data persistence layer. When implementing new business functions or modules, developers no longer need to write any repetitive code related to audit logs. They only need to declare the business entities to be audited in the dynamic configuration to automatically obtain complete data change record capabilities. This fundamentally eliminates the development workload caused by manually writing audit code and avoids the risks of coding errors and omissions. As a system-level foundational service, its maintenance and upgrades can be performed in one place, greatly reducing long-term maintenance costs and complexity, achieving excellent cost-effectiveness.

[0051] 2. Achieve non-intrusiveness and purity in business code. By leveraging the interception mechanism of the Object Relational Mapping (ORM) framework, change information is captured and processed uniformly at the data layer, achieving "zero intrusion" into the upper-layer business code. The business logic methods focus on their core CRUD operations and business rules, eliminating any bypass logic for logging, significantly improving the simplicity, readability, and maintainability of the business code. It also strictly adheres to the design principle of separation of concerns, making the software architecture clearer and more robust.

[0052] 3. Offers high flexibility and scalability A dynamic configuration center is introduced to manage the list of business entities requiring auditing, giving the system hot-swappable auditing capabilities. Operations personnel or system administrators can dynamically add, remove, or modify the list of business objects requiring auditing during system runtime, based on changes in business needs or adjustments to compliance requirements. All configuration changes take effect immediately on all subsequent operations, without requiring modification of any line of business code or service interruption for redeployment. This allows the system to quickly adapt to business development needs and provides exceptional scalability.

[0053] 4. Ensure the integrity and traceability of audit data. Differentiated data capture strategies are designed for different database operation types (add, modify, delete) to ensure that business objects are fully preserved in snapshots before and / or after any change scenario. These snapshots are typically stored in a structured format (such as JSON), clearly recording all details of data changes. By combining operation type, operator, precise timestamp, and business primary key, a complete, continuous, and associative data change pipeline is formed, providing reliable and detailed data evidence for subsequent security audits, problem investigation, data recovery, and accountability.

[0054] 5. Optimize system operation and maintenance and data governance experience By consolidating scattered data change information into a standardized business update record table, front-end applications can easily query and display the time-sorted change trajectory of any business document throughout its entire lifecycle, using business entity type and document primary key. This centralized and standardized data traceability capability greatly simplifies the process of troubleshooting and maintenance, improves the transparency and efficiency of data governance, and makes the flow and evolution of business data readily apparent.

[0055] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0056] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for recording the history of lightweight business data changes, characterized in that, The method includes: Step S1: Intercept and parse the data persistence operation initiated through the ORM framework to determine its operation type, the target business object involved, and the corresponding operation conditions; Step S2: Read the external dynamic configuration and determine whether the target business object is set as an audit object that needs to record change history based on the configuration information; Step S3: For audit objects that require recording change history, automatically execute data status capture and audit log generation corresponding to the operation type.

2. The method for recording the history of lightweight business data changes according to claim 1, characterized in that, Step S1 includes: using the extension mechanism provided by the ORM framework to intercept the SQL statement before it is executed, identifying its operation type by parsing the intercepted SQL statement, mapping the target data table in the SQL operation to a specific business object entity class according to the preset entity-table mapping relationship in the ORM framework, and extracting the conditional clauses in the operation to determine the affected data range.

3. The method for recording the history of lightweight business data changes according to claim 1, characterized in that, Step S2 includes: Maintain a dynamically updatable audit configuration list, which contains the fully qualified name or unique identifier of the entity class of the business object; The entity class information of the target business object is compared with the audit configuration list. If the entity class information of the target business object exists in the audit configuration list, the target business object is determined to need to be audited. If the entity class information of the target business object does not exist in the audit configuration list, it is directly allowed and the original data persistence operation is performed without any audit record.

4. The method for recording the history of lightweight business data changes according to claim 1, characterized in that, The dynamically updatable audit configuration list in step S2 is stored in an external configuration file or configuration center. It periodically listens for or receives change notifications for the audit configuration list in real time. When the contents of the list change, all subsequent data persistence operations are based on the changed audit configuration list for audit judgment.

5. The method for recording the history of lightweight business data changes according to claim 1, characterized in that, Step S3 includes: before and after performing the original data operation, obtaining the pre-change state data and / or post-change state data of the business object, generating an audit record containing operation context information, and persisting it to a dedicated storage.

6. The method for recording the history of lightweight business data changes according to claim 5, characterized in that, In step S3, an audit record containing operation context information is generated and persisted to a dedicated storage. This includes: constructing an audit record entity object with a fixed structure, which includes the operation type, business object entity class name, business object primary key value, object state before change serialized in JSON string format, object state after change serialized in JSON string format, operator identifier, and operation timestamp field. The audit record entity object is then saved to a business data audit table in the database, which is dedicated to storing change history, through the ORM framework.

7. The method for recording the history of lightweight business data changes according to claim 1, characterized in that, In step S3, when the operation type is "add", the new SQL operation is first allowed and executed to complete the data insertion. After the insertion operation is completed, the complete business object instance that has been persisted and whose primary key has been automatically generated by the database is directly obtained from the ORM framework context. The complete status data of the business object instance is used as the changed data. Combined with the operation type, object primary key, operator, and operation time, an audit record for the new operation is generated.

8. The method for recording the history of lightweight business data changes according to claim 1, characterized in that, In step S3, when the operation type is deletion, before executing the deletion SQL operation, a query statement is constructed based on the conditional clauses in the SQL, and the query statement is executed to obtain the complete status data of all business object instances that are about to be deleted, as the data before the change; Then, the original delete SQL operation is executed, and based on the data before the change retrieved, combined with the operation type, object primary key, operator, and operation time, an audit record for the deletion operation is generated for each deleted object.

9. The method for recording the history of lightweight business data changes according to claim 1, characterized in that, In step S3, when the operation type is update, before executing the update SQL operation, a query is constructed based on the update conditions to obtain the complete status data of the business object before the update, which is used as the data before the change; the update SQL operation is allowed and executed. After the update operation is executed, a query is constructed again based on the primary key or update conditions of the business object to obtain the complete status data of the same business object after the update, which is used as the data after the change. By using the business primary key, the data obtained before the change is associated with the data obtained after the change, and an update operation audit record is generated that includes the status before and after the change, operation type, object primary key, operator, and operation time.

10. A lightweight business data change history recording system, characterized in that, The system includes: The operation interception and parsing module is used to intercept and parse data persistence operations initiated through the ORM framework, and determine the operation type, the target business object involved, and the corresponding operation conditions. The audit configuration matching module is used to read external dynamic configurations and determine whether the target business object is set as an audit object whose change history needs to be recorded based on the configuration information. The history module is used to automatically capture data status and generate audit logs corresponding to the operation type for audit objects that require recording change history.

Images