Method and device for dynamically generating SQL (Structured Query Language) for data recovery through data change

Abstract

The invention provides a method and a device for dynamically generating an SQL (Structured Query Language) for data recovery through data change, and solves the problem of low system operation and maintenance efficiency in the prior art. When a log that a user modifies data needs to be recorded in a multi-page scene, a large number of redundant codes need to be output in back-end processing. The scene processing mode is abstracted and configured, and code development is simplified. According to the method, the problem positioning is faster, and the fault tolerance of the system is improved to a certain extent. The method has the characteristics of high reuse and low coupling, (1) attribute fields in entity classes are uniformly compared by mainly utilizing reflection, and the same points for recording user modification data logs in a multi-page scene are abstracted and modified, so that code development is simplified, and high reuse is realized; and (2) the user-defined annotation is applied, only the annotation needs to be introduced during use, the function is independent, no invasion is caused to the original interface, and low coupling is realized.

Description

Technical Field

[0001] The present invention relates to the field of system operation and maintenance, and in particular to a method and device for dynamically generating SQL for data recovery through data changes. Background Art

[0002] When operators configure the configuration management system, any carelessness may cause the online service process to be paralyzed, affecting the user experience.

[0003] The traditional approach is to take out the old data and back it up first after receiving the user's request, and then compare the old data with the requested input parameters after the business logic processing is completed. However, this approach will result in poor code reusability and a large amount of code redundancy during the code implementation process. At the same time, when the current data needs to be restored to the previous data, multiple operations are required to complete the data modification work. The process is cumbersome and error-prone, which is not conducive to production operation and maintenance, and thus affects the efficiency of system operation and maintenance. Summary of the invention

[0004] The present invention provides a method and device for dynamically generating SQL for data recovery through data changes, so as to solve the problem of low system operation and maintenance efficiency in the prior art.

[0005] In a first aspect, the present invention provides a method for dynamically generating SQL for data recovery based on data changes, which specifically comprises the following steps:

[0006] Step S1, modify or delete old data DATA1 through the front-end page, generate a business request and transmit the business request to the back-end;

[0007] Step S2: intercept the service request through the backend and load the old data DATA1 saved in the data table;

[0008] Step S3, modifying or deleting the old data DATA1 according to the service request to form new data DATA2;

[0009] Step S4, the backend intercepts the new data DATA2, and generates a unique identification code ID for this operation according to the new data DATA2 and the old data DATA1, and records the data change log and generates a database recovery statement;

[0010] Step S5: When the data DATA2 needs to be restored, the back end obtains the unique identification code ID, and retrieves and executes the database restoration statement according to the unique identification code ID to complete the data restoration.

[0011] Preferably, in step S1, when the data DATA1 is submitted for the first time, the Hash value of the data DATA1 is calculated as a unique identifier. When the front end subsequently obtains this data, the Hash value will be transmitted to the front end and placed in a hidden object. After the front end modifies the data, it will be submitted together with the Hash value and the data before the modification of the data will be found in the database for comparison.

[0012] Preferably, in step S2, the backend intercepts the business request and loads the old data DATA1 stored in the data table for synchronous processing, in order to prevent the business request from being directly stored in the warehouse due to the simplicity of the business.

[0013] Preferably, in step S4, the backend intercepts the new data DATA2, and generates a unique identification code ID for this operation based on the new data DATA2 and the old data DATA1, and records the data change log and generates a database recovery statement. The above steps are asynchronously processed to reduce the user's bad experience of long waiting time due to the time consumed in processing.

[0014] Preferably, in step S4, the backend intercepts the new data DATA2, generates a unique identification code ID for this operation according to the new data DATA2 and the old data DATA1, and records a data change log and generates a database recovery statement, which specifically includes the following steps:

[0015] Step S401, after intercepting the new data DATA2, the backend takes out all the fields in the new data DATA2;

[0016] Step S402, determining whether all fields include only unique identifiers of data, if all fields include only unique identifiers of data, executing step S403, otherwise, executing step S404;

[0017] Step S403, after converting the old data DATA1 into a database recovery statement, a unique identification code ID for this operation is generated, and after the data change log is deleted and saved, step S5 is executed;

[0018] Step S404, traverse all fields in the new data DATA2 to obtain the fields that need to record change logs;

[0019] Step S405: For each field that needs to record the change log, take out the field value with the same name as the field from the old data DATA1, and compare whether the field values ​​in the old data DATA1 and the new data DATA2 are the same. If they are the same, skip the field; otherwise, convert the old data DATA1 into a database recovery statement, generate a unique identification code ID for this operation, and record and save the field change through the data change log.

[0020] Preferably, in step S405, the reflection mechanism is used to compare whether the field values ​​in the old data DATA1 and the new data DATA2 are the same, allowing the program to access and modify the class information at runtime, including the class name, method name, parameter type, etc., and to dynamically create and operate objects. The reflection mechanism is used here to allow the compiled program to dynamically create data objects according to the current operation data when running. These data cannot be obtained in advance during program development.

[0021] Preferably, in step S5, when the data DATA2 needs to be restored, the backend obtains the unique identification code ID, and retrieves the database recovery statement according to the unique identification code ID, and the database recovery statement defaults to the most recent recovery statement.

[0022] In a second aspect, the present invention also provides a device for dynamically generating SQL for data recovery based on data changes, which specifically includes the following modules:

[0023] A business request generation module is used to modify or delete old data DATA1 through a front-end page, generate a business request and transmit the business request to a back-end;

[0024] An old data loading module, connected to the business request generating module, is used to intercept the business request through the backend and load the old data DATA1 saved in the data table;

[0025] A data processing module, connected to the old data loading module, for modifying or deleting the old data DATA1 according to the service request to form new data DATA2;

[0026] A data change record and recovery statement generation module, connected to the data processing module, is used for the back-end to intercept new data DATA2, generate a unique identification code ID for this operation based on the new data DATA2 and the old data DATA1, and record data change logs and generate database recovery statements;

[0027] The data recovery module is connected to the data change record and recovery statement generation module, and is used for obtaining the unique identification code ID at the back end when data DATA2 needs to be recovered, and taking out and executing the database recovery statement according to the unique identification code ID to complete data recovery.

[0028] Preferably, in the business request generation module, when the data DATA1 is submitted for the first time, the Hash value of the data DATA1 is calculated as a unique identifier. When the front end subsequently obtains this data, the Hash value will be transmitted to the front end and placed in a hidden object. After the front end modifies the data, it will be submitted together with the Hash value and the data before the modification of the data will be found in the database for comparison.

[0029] Preferably, in the old data loading module, the backend intercepts the business request and loads the old data DATA1 stored in the data table for synchronous processing, in order to prevent the business request from being directly stored in the warehouse due to simple business.

[0030] Preferably, in the data change record and recovery statement generation module, the backend intercepts the new data DATA2, and generates a unique identification code ID for this operation based on the new data DATA2 and the old data DATA1, and records the data change log and generates a database recovery statement. The above steps are asynchronously processed to reduce the user's adverse experience of long waiting time due to the time consumed in processing.

[0031] Preferably, the data change record and recovery statement generation module specifically includes the following submodules:

[0032] The first submodule is used to extract all fields of the new data DATA2 after the backend intercepts the new data DATA2;

[0033] The second submodule is connected to the first submodule and is used to determine whether all the fields include only the unique identifier of the data. If all the fields include only the unique identifier of the data, the third submodule is executed, otherwise, the fourth submodule is executed;

[0034] The third submodule is connected to the second submodule and is used to convert the old data DATA1 into a database recovery statement, generate a unique identification code ID for this operation, and execute the data recovery module after deleting and saving the data change log record;

[0035] A fourth submodule, connected to the second submodule, is used to traverse all fields in the new data DATA2 and obtain fields for which change logs need to be recorded;

[0036] The fifth submodule is connected to the fourth submodule and is used to extract the field value with the same name as the field from the old data DATA1 for each field in the fields that need to record the change log, and compare whether the field values ​​in the old data DATA1 and the new data DATA2 are the same. If they are the same, the field is skipped; otherwise, the old data DATA1 is converted into a database recovery statement, a unique identification code ID for this operation is generated, and the field change is recorded and saved through the data change log.

[0037] Preferably, in the fifth submodule, the reflection mechanism is used to compare whether the field values ​​in the old data DATA1 and the new data DATA2 are the same, allowing the program to access and modify the class information at runtime, including the class name, method name, parameter type, etc., and can dynamically create and operate objects. The reflection mechanism is used here to allow the compiled program to dynamically create data objects according to the current operation data when it is running. These data cannot be obtained in advance during program development.

[0038] Preferably, in the data recovery module, when the data DATA2 needs to be recovered, the backend obtains the unique identification code ID, and retrieves the database recovery statement according to the unique identification code ID, and the database recovery statement defaults to the most recent recovery statement.

[0039] In a third aspect, the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a method for dynamically generating SQL for data recovery through data changes as described in any one of the first aspects of the present application.

[0040] In a fourth aspect, the present invention further provides an electronic device, comprising: a memory storing a computer program; and a processor communicating with the memory, for executing, when calling the computer program, a method for dynamically generating SQL for data recovery through data changes as described in any one of the first aspects of the present application.

[0041] Compared with the prior art, the present invention has the following obvious outstanding substantial features and significant advantages: The present invention provides a method and device for dynamically generating SQL for data recovery through data changes, which solves the problem of low system operation and maintenance efficiency in the prior art. When a multi-page scenario needs to record a log of user modification of data, the back-end processing needs to output a large amount of redundant code. The present invention abstracts and configures the processing method of this scenario to simplify code development. The present invention is faster for problem location and increases the system fault tolerance to a certain extent. The present invention has the characteristics of high reuse and low coupling. (1) It mainly uses reflection to uniformly compare the attribute fields in the entity class, abstracts the similarities of the log recording user modification of data in the multi-page scenario and modifies it, thereby simplifying code development and achieving high reuse; (2) It uses custom annotations, and only needs to introduce the annotations when using it. The functions are independent and non-invasive to the original interface, achieving low coupling. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The accompanying drawings, which constitute part of the present invention, are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations on the present invention. In the accompanying drawings:

[0043] Figure 1The present invention is a flowchart of a method for dynamically generating SQL for data recovery through data changes according to a preferred embodiment of the present invention.

[0044] Figure 2 It is a schematic diagram of the structure of a device for dynamically generating SQL for data recovery through data changes according to a preferred embodiment of the present invention. DETAILED DESCRIPTION

[0045] The present invention provides a method and device for dynamically generating SQL for data recovery through data changes. In order to make the purpose, technical solution and effect of the present invention clearer and more specific, the present invention is further described in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0046] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes 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.

[0047] Embodiment 1:

[0048] In the process of configuration management of the online service system, any carelessness of the operator during configuration may cause the online service process to be paralyzed, affecting user use.

[0049] When operators want to change back to old data during the configuration management of the online service system, they need to implement two processes: recording the data changes from old data to new data and restoring the new data to old data.

[0050] 1. Record data changes

[0051] The usual practice is to take out and back up the old data first after receiving the user request. After the business logic processing is completed, the old data is compared with the input parameters of the request. The comparison method is as follows:

[0052] / / Backup old data

[0053] Object old = new Object();

[0054] / / Request input

[0055] Object new = new Object();

[0056] / / Record log object

[0057] Log log = new Log();

[0058] if(!old.get("x").equals(new.get("x"))){

[0059] log.add("Field x is changed from {old.get("x")} to {new.get("x")}");

[0060] }

[0061] if(!old.get("y").equals(new.get("y"))){

[0062] log.add("Field y is changed from {old.get("y")} to {new.get("y")}");

[0063] } ......

[0065] The number of if conditions is equal to the number of fields in the object. If there are too many fields in the object, the number of if conditions will also increase. If other scenarios also need to record data changes, the same logic needs to be written again. This method is not universal and cannot achieve the purpose of code reuse. It also generates a lot of redundant code.

[0066] 2. Recover data

[0067] The usual practice is to just record what the data has been changed to. If you want to restore the data before the change, you have to manually edit and save it again. The usual practice requires clicking the button many times to restore the modified data. The usual practice is cumbersome, error-prone, and not conducive to production operation and maintenance.

[0068] Therefore, the present invention proposes a method and device for dynamically generating SQL for data recovery through data changes.

[0069] like Figure 1 As shown, a method for dynamically generating SQL for data recovery through data changes according to this embodiment is described, which specifically includes the following steps:

[0070] Step S1, modify or delete old data DATA1 through the front-end page, generate a business request and transmit the business request to the back-end.

[0071] Optionally, when data DATA1 is submitted for the first time, the Hash value of data DATA1 is calculated as a unique identifier. When the front end subsequently obtains this data, the Hash value will be transmitted to the front end and placed in a hidden object. After the front end modifies the data, it will be submitted together with the Hash value and the data before the modification of the data will be found in the database for comparison.

[0072] Optionally, the backend intercepts the business request and loads the old data DATA1 stored in the data table for synchronous processing, in order to prevent the business request from being directly stored in the database due to the simplicity of the business.

[0073] Step S2: intercept the service request through the backend and load the old data DATA1 saved in the data table.

[0074] Step S3: modify or delete the old data DATA1 according to the service request to form new data DATA2.

[0075] Step S4, the backend intercepts the new data DATA2, and generates a unique identification code ID for this operation according to the new data DATA2 and the old data DATA1, and records a data change log and generates a database recovery statement.

[0076] Optionally, the above steps are asynchronous processing to reduce the bad experience of long waiting time caused by the time consumed by processing. The asynchronous processing does not mean that all the processes described in this paragraph must be completed before continuing the actual business process. It is an independent sub-thread that is executed and has no order relationship with the main thread of the business process.

[0077] Optionally, in step S4, the backend intercepts the new data DATA2, generates a unique identification code ID for this operation according to the new data DATA2 and the old data DATA1, and records a data change log and generates a database recovery statement, specifically including the following steps:

[0078] Step S401: After intercepting new data DATA2, the backend takes out all fields in the new data DATA2.

[0079] Step S402, determine whether all fields include only unique identifiers of data, if all fields include only unique identifiers of data, execute step S403, otherwise, execute step S404.

[0080] Step S403, after converting the old data DATA1 into a database recovery statement, a unique identification code ID for this operation is generated, and after the data change log record is deleted and saved, step S5 is executed.

[0081] Step S404: traverse all fields in the new data DATA2 to obtain fields for which change logs need to be recorded.

[0082] Step S405: For each field that needs to record the change log, take out the field value with the same name as the field from the old data DATA1, and compare whether the field values ​​in the old data DATA1 and the new data DATA2 are the same. If they are the same, skip the field; otherwise, convert the old data DATA1 into a database recovery statement, generate a unique identification code ID for this operation, and record and save the field change through the data change log.

[0083] Optionally, the reflection mechanism is used to compare whether the field values ​​in the old data DATA1 and the new data DATA2 are the same, allowing the program to access and modify class information at runtime, including class name, method name, parameter type, etc., and to dynamically create and operate objects. The reflection mechanism is used here to allow the compiled program to dynamically create data objects according to the current operation data when it is running. These data cannot be obtained in advance during program development.

[0084] Step S5: When the data DATA2 needs to be restored, the back end obtains the unique identification code ID, and retrieves and executes the database restoration statement according to the unique identification code ID to complete the data restoration.

[0085] Optionally, when the data DATA2 needs to be restored, the backend obtains the unique identification code ID, and retrieves a database recovery statement according to the unique identification code ID. The database recovery statement defaults to the most recent recovery statement.

[0086] Embodiment 2:

[0087] like Figure 2 As shown, the device for dynamically generating SQL for data recovery through data changes described in this embodiment specifically includes the following modules:

[0088] The business request generation module is used to modify or delete the old data DATA1 through the front-end page, generate a business request and transmit the business request to the back-end.

[0089] Optionally, in the business request generation module, when the data DATA1 is submitted for the first time, the Hash value of the data DATA1 is calculated as a unique identifier. When the front end subsequently obtains this data, the Hash value will be transmitted to the front end and placed in a hidden object. After the front end modifies the data, it will be submitted together with the Hash value and the data before the modification of the data will be found in the database for comparison.

[0090] The old data loading module is connected to the business request generating module, and is used to intercept the business request through the back end and load the old data DATA1 saved in the data table.

[0091] Optionally, in the old data loading module, the backend intercepts the business request and loads the old data DATA1 stored in the data table for synchronous processing, in order to prevent the business request from being directly stored in the warehouse due to simple business operations.

[0092] The data processing module is connected to the old data loading module and is used to modify or delete the old data DATA1 according to the service request to form new data DATA2.

[0093] The data change record and recovery statement generation module is connected to the data processing module, and is used for the back-end to intercept new data DATA2, and generate a unique identification code ID for this operation based on the new data DATA2 and the old data DATA1, and record the data change log and generate a database recovery statement.

[0094] Optionally, in the data change record and recovery statement generation module, the backend intercepts the new data DATA2, and generates a unique identification code ID for this operation based on the new data DATA2 and the old data DATA1, and records the data change log and generates a database recovery statement. The above steps are asynchronously processed to reduce the user's adverse experience of long waiting time due to the time consumed in processing.

[0095] Optionally, the data change record and recovery statement generation module specifically includes the following submodules:

[0096] The first submodule is used to extract all fields in the new data DATA2 after the backend intercepts the new data DATA2.

[0097] The second submodule is connected to the first submodule and is used to determine whether all fields include only unique identifiers of data. If all fields include only unique identifiers of data, the third submodule is executed, otherwise, the fourth submodule is executed.

[0098] The third submodule is connected to the second submodule and is used to convert the old data DATA1 into a database recovery statement, generate a unique identification code ID for this operation, and execute the data recovery module after deleting and saving the data change log record.

[0099] The fourth submodule is connected to the second submodule and is used to traverse all fields in the new data DATA2 and obtain the fields for which change logs need to be recorded.

[0100] The fifth submodule is connected to the fourth submodule and is used to extract the field value with the same name as the field from the old data DATA1 for each field in the fields that need to record the change log, and compare whether the field values ​​in the old data DATA1 and the new data DATA2 are the same. If they are the same, the field is skipped; otherwise, the old data DATA1 is converted into a database recovery statement, a unique identification code ID for this operation is generated, and the field change is recorded and saved through the data change log.

[0101] Optionally, in the fifth sub-module, the reflection mechanism is used to compare whether the field values ​​in the old data DATA1 and the new data DATA2 are the same, allowing the program to access and modify the class information at runtime, including the class name, method name, parameter type, etc., and to dynamically create and operate objects. The reflection mechanism is used here to allow the compiled program to dynamically create data objects according to the current operation data when it is running. These data cannot be obtained in advance during program development.

[0102] The data recovery module is connected to the data change record and recovery statement generation module, and is used for obtaining the unique identification code ID at the back end when data DATA2 needs to be recovered, and taking out and executing the database recovery statement according to the unique identification code ID to complete data recovery.

[0103] Optionally, when the data DATA2 needs to be restored, the backend obtains the unique identification code ID, and retrieves a database recovery statement according to the unique identification code ID. The database recovery statement defaults to the most recent recovery statement.

[0104] The specific embodiments of the present invention are described in detail above, but they are only examples, and the present invention is not limited to the specific embodiments described above. For those skilled in the art, any equivalent modifications and substitutions made to the present invention are also within the scope of the present invention. Therefore, the equalization changes and modifications made without departing from the spirit and scope of the present invention should be included in the scope of the present invention.

Claims

1. A method for dynamically generating SQL for data recovery through data changes, characterized in that: The specific steps include: Step S1, modify or delete old data DATA1 through the front-end page, generate a business request and transmit the business request to the back-end; Step S2: intercept the service request through the backend and load the old data DATA1 saved in the data table; Step S3, modifying or deleting the old data DATA1 according to the service request to form new data DATA2; Step S4, the backend intercepts the new data DATA2, and generates a unique identification code ID for this operation according to the new data DATA2 and the old data DATA1, and records the data change log and generates a database recovery statement; Step S5: When the data DATA2 needs to be restored, the back end obtains the unique identification code ID, and retrieves and executes the database restoration statement according to the unique identification code ID to complete the data restoration.

2. A method for dynamically generating SQL for data recovery through data changes according to claim 1, characterized in that: In step S1, when data DATA1 is submitted for the first time, the Hash value of data DATA1 is calculated as a unique identifier. When the front end subsequently obtains this data, the Hash value will be transmitted to the front end and placed in a hidden object. After the front end modifies the data, it will be submitted together with the Hash value and the data before the modification of the data will be found in the database for comparison.

3. The method for dynamically generating SQL for data recovery through data changes according to claim 1, characterized in that: In step S2, the backend intercepts the business request and loads the old data DATA1 stored in the data table for synchronous processing, in order to prevent the business request from being directly stored in the database due to the simplicity of the business.

4. The method for dynamically generating SQL for data recovery through data changes according to claim 1, characterized in that: In step S4, the backend intercepts the new data DATA2, and generates a unique identification code ID for this operation based on the new data DATA2 and the old data DATA1, and records the data change log and generates a database recovery statement. The above steps are asynchronously processed to reduce the user's bad experience of long waiting time due to the time consumed in processing.

5. The method for dynamically generating SQL for data recovery through data changes according to claim 1, characterized in that: In step S4, the backend intercepts the new data DATA2, generates a unique identification code ID for this operation based on the new data DATA2 and the old data DATA1, and records the data change log and generates a database recovery statement, which specifically includes the following steps: Step S401, after intercepting the new data DATA2, the backend takes out all the fields in the new data DATA2; Step S402, determining whether all fields include only unique identifiers of data, if all fields include only unique identifiers of data, executing step S403, otherwise, executing step S404; Step S403, after converting the old data DATA1 into a database recovery statement, a unique identification code ID for this operation is generated, and after the data change log is deleted and saved, step S5 is executed; Step S404, traverse all fields in the new data DATA2 to obtain the fields that need to record change logs; Step S405: For each field that needs to record the change log, take out the field value with the same name as the field from the old data DATA1, and compare whether the field values ​​in the old data DATA1 and the new data DATA2 are the same. If they are the same, skip the field; otherwise, convert the old data DATA1 into a database recovery statement, generate a unique identification code ID for this operation, and record and save the field change through the data change log.

6. A method for dynamically generating SQL for data recovery through data changes according to claim 5, characterized in that: In step S405, the reflection mechanism is used to compare whether the field values ​​in the old data DATA1 and the new data DATA2 are the same, allowing the program to access and modify the class information at runtime, including the class name, method name, parameter type, etc., and to dynamically create and operate objects. The reflection mechanism is used here to allow the compiled program to dynamically create data objects according to the current operation data when it is running. These data cannot be obtained in advance during program development.

7. The method for dynamically generating SQL for data recovery through data changes according to claim 1, characterized in that: In step S5, when the data DATA2 needs to be restored, the backend obtains the unique identification code ID, and retrieves the database recovery statement according to the unique identification code ID. The database recovery statement defaults to the most recent recovery statement.

8. A device for dynamically generating SQL for data recovery based on data changes, characterized in that: Specifically, it includes the following modules: a business request generation module, which is used to modify or delete old data DATA1 through the front-end page, generate a business request and transmit the business request to the back-end; An old data loading module, connected to the business request generating module, is used to intercept the business request through the backend and load the old data DATA1 saved in the data table; A data processing module, connected to the old data loading module, for modifying or deleting the old data DATA1 according to the service request to form new data DATA2; A data change record and recovery statement generation module, connected to the data processing module, is used for the back-end to intercept new data DATA2, generate a unique identification code ID for this operation based on the new data DATA2 and the old data DATA1, and record data change logs and generate database recovery statements; The data recovery module is connected to the data change record and recovery statement generation module, and is used for obtaining the unique identification code ID at the back end when data DATA2 needs to be recovered, and taking out and executing the database recovery statement according to the unique identification code ID to complete data recovery.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method for dynamically generating SQL for data recovery through data changes according to any one of claims 1 to 7 is implemented.

10. An electronic device, characterized in that: The method comprises a memory, a processor and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the method for dynamically generating SQL for data recovery through data changes as described in any one of claims 1 to 7 is implemented.

Images