A data verification method and device, electronic equipment and medium
By adding annotations to the application code to generate database trigger scripts, the problems of low efficiency of Hibernate Validator and low development efficiency of database triggers are solved, and efficient data validation and automated validation processes across databases are achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHONGQING JINKANG NEW ENERGY VEHICLE CO LTD
- Filing Date
- 2026-03-31
- Publication Date
- 2026-06-26
AI Technical Summary
In existing technologies, Hibernate Validator has low running efficiency, cannot cover data operations through direct SQL connections and other methods such as third-party tools, and has low development efficiency and high maintenance costs across databases.
By adding first and second validation information annotations to the application code, trigger scripts for different database types are generated, and these scripts are executed in the target database to automatically respond to data change operations and perform validation.
It improves the efficiency of data validation and development, reduces the maintenance cost across databases, can adapt to various data input methods and automatically perform validation without the need to manually write SQL scripts.
Smart Images
Figure CN122285646A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of computer software technology, and specifically relates to a data verification method, device, electronic device, and medium. Background Technology
[0002] Currently, data validation is typically implemented using Java-based validation frameworks such as Hibernate Validator, which are based on JSR380 (Java Specification Request 380). Developers define validation rules through annotations, offering the advantage of high development efficiency. On the other hand, database triggers automatically execute preset SQL (Structured Query Language) logic when data operations occur, eliminating the need for manual invocation and offering the advantage of high runtime efficiency.
[0003] However, in existing technologies, Hibernate Validator has low runtime efficiency and can only validate data through the Java application entry point, failing to cover data operations from direct SQL connections, third-party tools, and other means. While database triggers are highly efficient, they require manually writing SQL scripts, resulting in low development efficiency. Furthermore, the syntax differences between different database triggers lead to high maintenance costs when developing across databases, thus affecting the efficiency of data validation. Summary of the Invention
[0004] The purpose of this application is to provide a data verification method, apparatus, electronic device, and medium.
[0005] In a first aspect, embodiments of this application provide a data verification method, the method comprising: Obtain the application code, which contains a first validation information annotation set for an entity class and a second validation information annotation set for a field in the entity class; For different database types, different trigger scripts are generated based on the first verification information annotation and the second verification information annotation respectively; Obtain the target database currently connected to by the application and determine the target database type of the target database; then, determine the target trigger script that matches the target database type from the generated trigger script. Execute the target trigger script on the target database to generate the target trigger; In response to a data change operation for the application, obtain data change information; The target trigger is used to verify the data change information to obtain the data verification result.
[0006] Optionally, the step of generating different trigger scripts based on the first verification information annotation and the second verification information annotation for different database types includes: Parse the first verification information annotation to obtain the verification control information of the entity class; Parse the second verification information annotation to obtain the field verification information of the field; For different database types, different trigger scripts are generated for each entity class based on the verification control information and the field verification information; wherein, the trigger script corresponding to each entity class is used to generate the trigger corresponding to the entity class after being executed.
[0007] Optionally, the verification control information includes at least one of the following: Database deployment identifier, used to indicate whether the field validation information is deployed to the database; A flexible verification flag is used to indicate whether to interrupt the operation when verification fails; A logging flag is used to indicate whether a log should be logged when a verification fails. The log table specifies information used to record log entries for verification failures. The operation type specification information is used to specify the type of business operation that triggers the verification.
[0008] Optionally, the field validation information includes at least one of the following: The NOT NULL check flag is used to indicate that a field value cannot be empty; Length validation flags are used to indicate the length range of field values; Numerical validation flags are used to indicate the numerical range of field values; Format validation flags are used to indicate the format that a field value must match; Date validation flags are used to indicate the time attribute of a field value; Boolean check flags are used to indicate the Boolean state of a field value.
[0009] Optionally, the step of using the target trigger to verify the data change information and obtaining the data verification result includes: When the database deployment identifier indicates that the field validation information is deployed to the database, a target trigger is created for each entity class to determine whether the data change information meets the validation conditions corresponding to the field validation information in the entity class. If the data change information meets the verification conditions, the data verification result is determined to be passed, and the data change operation continues to be executed; If the data change information does not meet the verification conditions, and the flexible verification flag indicates an interruption operation, then the data verification result is determined to be a failure, and the data change operation is stopped. If the data change information does not meet the verification conditions, and the flexible verification flag indicates that the operation should not be interrupted, then the data verification result is determined to be a failure, the data change operation continues, and the verification failure information is recorded according to the log record flag, the log table specified information, and the operation type specified information.
[0010] Optionally, the step of obtaining the target database currently connected to by the application and determining the target database type of the target database, and determining the target trigger script that matches the target database type from the generated trigger script, includes: Obtain the database type of the target database currently being connected to by the application, and use it as the target database type; From the multiple trigger scripts generated for each entity class, select the trigger script that matches the target database type and use it as the target trigger script for each entity class.
[0011] Optionally, the step of executing the target trigger script against the target database to generate the target trigger includes: When the application starts, a target trigger script that matches the target database type for each entity class is executed in the target database, and the information of the executed trigger scripts is recorded. After the target trigger script is executed, a corresponding target trigger is generated for each entity class.
[0012] Secondly, embodiments of this application provide a data verification device, the device comprising: The code acquisition module is used to acquire the application's code, which includes a first verification information annotation set for entity classes and a second verification information annotation set for fields in the entity classes. The script generation module is used to generate different trigger scripts for different database types based on the first verification information annotation and the second verification information annotation. The script selection module is used to obtain the target database currently connected to by the application and determine the target database type of the target database, and to determine the target trigger script that matches the target database type from the generated trigger scripts; The trigger generation module is used to execute the target trigger script against the target database and generate a target trigger; The data change module is used to obtain data change information in response to data change operations for the application. The verification result acquisition module is used to verify the data change information using the target trigger and obtain the data verification result.
[0013] Thirdly, embodiments of this application provide an electronic device, including a processor, a memory, and a program or instructions stored in the memory and capable of running on the processor, wherein the program or instructions, when executed by the processor, implement the method described above.
[0014] Fourthly, a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the method described above.
[0015] The embodiments of this application have the following advantages: In this embodiment, by acquiring the application's code, which includes first verification information annotations for entity classes and second verification information annotations for fields within the entity classes, different trigger scripts are generated based on the first and second verification information annotations for different database types. This application only requires writing annotations in the code to generate trigger scripts, eliminating the need for manual writing and improving development efficiency. Furthermore, this application can generate different trigger scripts for different database types, adapting to various database types and ensuring development efficiency while reducing maintenance costs even in cross-database development. This application obtains the target database currently connected to by the application and determines the target database type. It then selects a target trigger script matching the target database type from the generated trigger scripts, executes the target trigger script for the target database, and generates a target trigger. Regardless of the data input source, it is ultimately written to the database. Since the triggers in this application are generated specifically for the database and deployed on it, the trigger is activated whenever an operation reaches the database. This allows for validation of data input from various sources, including Java application entry points, direct SQL connections, and third-party tools. In response to data change operations on the application, this application acquires data change information, uses a target trigger to validate the data change information, and obtains the data validation result. Since the verification process is executed automatically by triggers, it eliminates the need for network transmission and object creation, significantly improving the efficiency of data verification. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.
[0017] Figure 1 This is a flowchart illustrating the steps of a data verification method provided in an embodiment of this application; Figure 2 This is a logical schematic diagram of a data verification method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a data verification device provided in an embodiment of this application. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been presented in the various embodiments of this application to enable readers to better understand this application. However, the technical solutions claimed in this application can be implemented even without these technical details and various changes and updates based on the following embodiments. The division of the various embodiments below is for the convenience of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.
[0019] Reference Figure 1 The diagram shows a flowchart of the steps of a data verification method provided in an embodiment of this application.
[0020] The method may specifically include the following steps: Step 101: Obtain the application code, which contains a first verification information annotation set for the entity class and a second verification information annotation set for the fields in the entity class.
[0021] In this embodiment of the application, the application code can be obtained first. The code includes several entity classes.
[0022] In practical implementation, when writing the application, programmers can add a first validation information annotation to the entity class and a second validation information annotation to the fields of the entity class. The first validation information annotation defines validation control information at the entity class level, while the second validation information annotation defines specific validation rules at the field level. The application code is retrieved during compilation for subsequent processing.
[0023] In this context, an entity class refers to a Java class in the application used to map database tables; each entity class corresponds to one table in the database. Fields refer to member variables defined in the entity class; each field corresponds to a column in the database table.
[0024] In a specific implementation, the first validation information annotation can be FlexibleValid (flexible validation annotation). FlexibleValid is a custom annotation that contains the definition of the validation processing strategy.
[0025] The second validation annotation can be a validation annotation provided by the Hibernate Validator framework, including non-empty validation annotations, length validation annotations, and numeric range validation annotations.
[0026] Step 102: For different database types, generate different trigger scripts based on the first verification information annotation and the second verification information annotation.
[0027] In this embodiment of the application, during the code compilation stage, corresponding trigger scripts can be generated for different database types based on the first verification information annotation and the second verification information annotation.
[0028] In practical implementation, the annotation processor can scan all entity classes with the first verification information annotation, parse the first verification information annotation to obtain the verification control information, parse the second verification information annotation to obtain the field verification information, and combine the verification control information and the field verification information to generate a trigger script.
[0029] Because the trigger syntax differs between different databases, this application can generate corresponding trigger scripts for database types such as MySQL (an open-source relational database management system), Oracle (an enterprise-level relational database management system), and PostgreSQL (an open-source object-relational database management system), and package the generated scripts into the application's deployment package.
[0030] Annotation processors are a feature provided by the Java compiler tools that are used to scan and process annotations at compile time.
[0031] Verification control information may include whether to generate triggers, how to handle verification failures, and log table information.
[0032] Field validation information can include specific rules such as non-empty validation, length validation, and numerical range validation.
[0033] Step 103: Obtain the target database currently connected to by the application and determine the target database type of the target database. Then, determine the target trigger script that matches the target database type from the generated trigger script.
[0034] In this embodiment of the application, the database that the application is currently actually connected to can be obtained as the target database during application deployment or runtime, and the database type of the target database can be determined.
[0035] In practice, the address and type of the target database can be determined by reading the application's database connection configuration. Based on the determined target database type, the script that matches the database type is selected from multiple generated trigger scripts as the target trigger script, ensuring that the syntax of the subsequently executed script is compatible with the target database.
[0036] The target database can be the database that the application actually connects to and manipulates during runtime.
[0037] The target database type can refer to the type of database the target database belongs to, such as MySQL, Oracle, PostgreSQL, etc.
[0038] Step 104: Execute the target trigger script for the target database to generate the target trigger.
[0039] In this embodiment of the application, a target trigger script can be executed in the target database, and a corresponding trigger will be created in the target database after the script is executed.
[0040] In practice, the target trigger script can be automatically executed using a database migration tool when the application starts. This tool records the executed script information to avoid duplicate execution. After the script executes successfully, the target trigger is deployed on the database table, waiting to be automatically executed when data operations occur.
[0041] The target trigger can refer to the actual database trigger object created in the target database and deployed on a specific database table.
[0042] Database migration tools are tools used to automate the management of database structure changes. They can automatically execute database scripts and record the execution status when the application starts.
[0043] A database table is a two-dimensional structure used to store data in a database. Triggers are created on specific database tables and are only triggered when data operations occur on that table.
[0044] In its implementation, the target trigger of this application can be deployed on a database table. When the application manipulates data through the entity class, it ultimately translates into SQL operations on the database table, thereby triggering the trigger deployed on that table. Since the fields in the entity class correspond one-to-one with the columns in the database table, the validation rules defined by the second validation information annotation on the fields will ultimately be converted into validation of the corresponding columns in the database table.
[0045] Step 105: In response to a data change operation for the application, obtain data change information.
[0046] In this embodiment of the application, when a data change operation occurs during the operation of the application, such as inserting, updating or deleting a database table, the data change information involved in the operation can be obtained.
[0047] In practice, data modification operations can be initiated by the application through an ORM (Object Relational Mapping) framework, by a direct SQL connection tool, or by a third-party system or data import tool. Regardless of the source of the data modification operation, it will ultimately be translated into the execution of SQL statements on the target database.
[0048] Data modification operations can refer to insert, update, or delete operations performed on database tables.
[0049] Data change information can refer to the specific information involved in a data change operation, including the operation type, the name of the table being operated on, the field names, and the specific data values.
[0050] Step 106: Use the target trigger to verify the data change information and obtain the data verification result.
[0051] In this embodiment, the target trigger can be automatically triggered when a data change operation occurs. The target trigger verifies the acquired data change information based on the verification control information defined in the first verification information annotation and the field verification information defined in the second verification information annotation, and obtains the data verification result.
[0052] In its implementation, the trigger checks whether the data value meets validation conditions such as not empty, length range, and numerical range. If the validation conditions are met, the data validation result is passed, and the data modification operation continues. If the validation conditions are not met, further processing methods can be determined based on the validation control information.
[0053] The data verification result can be either a pass or a failure result obtained after the trigger verifies the data change information.
[0054] The verification failure information can include the table name, field name, data value, operation type, timestamp, and error description.
[0055] In this embodiment, by acquiring the application's code, which includes first verification information annotations for entity classes and second verification information annotations for fields within the entity classes, different trigger scripts are generated based on the first and second verification information annotations for different database types. This application only requires writing annotations in the code to generate trigger scripts, eliminating the need for manual writing and improving development efficiency. Furthermore, this application can generate different trigger scripts for different database types, adapting to various database types and ensuring development efficiency while reducing maintenance costs even in cross-database development. This application obtains the target database currently connected to by the application and determines the target database type. It then selects a target trigger script matching the target database type from the generated trigger scripts, executes the target trigger script for the target database, and generates a target trigger. Regardless of the data input source, it is ultimately written to the database. Since the triggers in this application are generated specifically for the database and deployed on it, the trigger is activated whenever an operation reaches the database. This allows for validation of data input from various sources, including Java application entry points, direct SQL connections, and third-party tools. In response to data change operations on the application, this application acquires data change information, uses a target trigger to validate the data change information, and obtains the data validation result. Since the verification process is executed automatically by triggers, it eliminates the need for network transmission and object creation, significantly improving the efficiency of data verification.
[0056] Optionally, in this embodiment of the application, the step of generating different trigger scripts based on the first verification information annotation and the second verification information annotation for different database types includes: S11, parse the first verification information annotation to obtain the verification control information of the entity class; S12, parse the second verification information annotation to obtain the field verification information of the field; S13, for different database types, different trigger scripts are generated for each entity class according to the verification control information and the field verification information; wherein, the trigger script corresponding to each entity class is used to generate the trigger corresponding to the entity class after being executed.
[0057] In this embodiment of the application, the first verification information annotation can be parsed first to obtain the verification control information of the entity class.
[0058] In practice, the annotation processor can scan all entity classes with annotations containing first verification information, parse the first verification information annotation on each entity class, and extract the verification control information contained in the annotation.
[0059] Among them, the verification control information can refer to the processing strategy defined in the first verification information annotation, which may include whether to deploy the field verification information to the database, whether to interrupt the operation when the verification fails, whether to log when the verification fails, the log table used when logging, and the operation type used when logging.
[0060] In this embodiment of the application, the second verification information annotation can be parsed to obtain the field verification information of the field.
[0061] In its implementation, the annotation processor iterates through all fields in each entity class, parses the second validation information annotation on each field, and extracts the field validation information corresponding to each field. The field validation information defines the specific validation rules for that field.
[0062] The field validation information can refer to the specific validation rules defined in the second validation information annotation, which may include rules such as non-empty validation, length validation, numeric validation, format validation, date validation, and Boolean validation.
[0063] In this embodiment, trigger scripts can be generated for different database types based on verification control information and field verification information.
[0064] In the specific implementation, for each entity class, the validation control information of the entity class and the field validation information of all fields in the entity class can be combined to generate a complete trigger rule.
[0065] Because trigger syntax differs across databases, trigger scripts with corresponding syntax versions need to be generated for database types such as MySQL, Oracle, and PostgreSQL.
[0066] Each entity class corresponds to a set of trigger scripts. These trigger scripts contain complete validation rules for the database tables mapped to that entity class. When the trigger script is executed in the target database, a corresponding trigger will be created on the database table corresponding to that entity class.
[0067] Trigger scripts refer to SQL script files that contain trigger creation statements. When the script is executed in the database, the corresponding trigger will be created on the specified database table.
[0068] This application solves the technical problems of low development efficiency and difficulty in cross-database portability of manually writing database triggers by parsing the first verification information annotation to obtain verification control information and the second verification information annotation to obtain field verification information, and generates corresponding trigger scripts for each entity class for different database types. It realizes that trigger scripts adapted to multiple databases can be automatically generated by simply writing annotations, which significantly improves development efficiency and reduces the maintenance cost of cross-database development.
[0069] Optionally, the verification control information includes at least one of the following: Database deployment identifier, used to indicate whether the field validation information is deployed to the database; A flexible verification flag is used to indicate whether to interrupt the operation when verification fails; A logging flag is used to indicate whether a log should be logged when a verification fails. The log table specifies information used to record log entries for verification failures. The operation type specification information is used to specify the type of business operation that triggers the verification.
[0070] In this embodiment, the database deployment identifier is used to control whether the field validation information is actually deployed to the database.
[0071] In the specific implementation, when the database deployment flag is "yes", it means that a trigger script needs to be generated for the current entity class and a trigger needs to be created in the database; when the database deployment flag is "no", it means that a trigger script does not need to be generated, and only the annotation validation of the application layer is retained.
[0072] In this embodiment, the flexible verification identifier is used to define the handling method when verification fails.
[0073] In the specific implementation, when the flexible verification flag indicates that the operation should be interrupted, if the data verification fails, the database trigger will reject the data change operation and throw an error; when the flexible verification flag indicates that the operation should not be interrupted, the database trigger will still allow the data change operation to continue even if the data verification fails.
[0074] In this embodiment of the application, the log recording identifier is used to control whether to record the verification failure information in the log table.
[0075] In the specific implementation, when the logging flag indicates that logging should be recorded, the trigger will write the failure information to the specified log table after the verification fails; when the logging flag indicates that logging should not be recorded, the trigger will not record logs after the verification fails.
[0076] The log table is a database table specifically used to store verification failure records. It includes fields such as table name, field name, error message, operation type, and timestamp.
[0077] In this embodiment, the log table specification information is used to specify the specific log table for recording verification failure information. In a specific implementation, when the log record identifier indicates that a log should be recorded, the trigger finds the corresponding log table based on the log table specification information and inserts the verification failure information into that table.
[0078] In this embodiment, the operation type specification information is used to identify the type of business operation that triggered this verification.
[0079] In the specific implementation, the operation type specification information can be a business operation identifier such as user registration, data import, data synchronization, data cleaning, system backup, system recovery, automatic repair, or manual correction. This information is written to the log table along with the log entries, facilitating subsequent categorization, querying, and processing of verification failure records.
[0080] This application addresses the problems of traditional verification schemes, such as their singular processing methods and inflexible failure strategy configuration, by setting database deployment identifiers, flexible verification identifiers, log recording identifiers, log table specification information, and operation type specification information in the verification control information. It achieves fine-grained control over verification behavior, allowing developers to flexibly configure whether to deploy database verification, whether to interrupt the operation when verification fails, whether to record logs, and which log table to record them in, according to business needs. At the same time, the operation type identifier facilitates subsequent classification, querying, and processing of verification failure records.
[0081] Optionally, the field validation information includes at least one of the following: The NOT NULL check flag is used to indicate that a field value cannot be empty; Length validation flags are used to indicate the length range of field values; Numerical validation flags are used to indicate the numerical range of field values; Format validation flags are used to indicate the format that a field value must match; Date validation flags are used to indicate the time attribute of a field value; Boolean check flags are used to indicate the Boolean state of a field value.
[0082] In this embodiment of the application, the non-empty check flag is used to define whether the field value is allowed to be empty.
[0083] In practical implementation, when a field is marked with a NOT NULL validation flag, it indicates that the value of that field cannot be blank during data operations. The NOT NULL validation flag corresponds to the NOT NULL annotation in Hibernate Validator.
[0084] In this embodiment, the length check flag is used to define the length range of a string type or collection type field.
[0085] In practice, the length validation flag can include two parameters: minimum length and maximum length, used to limit the number of characters or elements in a field value. The length validation flag corresponds to the length validation annotation in Hibernate Validator.
[0086] In this embodiment of the application, the numerical verification identifier is used to define the value range of the numerical type field.
[0087] In practical implementations, numeric validation flags can include two parameters: minimum and maximum value, used to limit the numerical value of a field. Numeric validation flags correspond to the minimum and maximum value validation annotations in Hibernate Validator.
[0088] In this embodiment of the application, the format validation identifier is used to define the specific format that the field value must conform to.
[0089] In practical implementations, format validation tags can contain regular expressions to verify whether field values conform to predefined format requirements, such as mobile phone number formats or ID card number formats. Format validation tags correspond to regular expression validation annotations in HibernateValidator.
[0090] In this embodiment of the application, the date verification identifier is used to define the time attribute of the date type field.
[0091] In practical implementations, date validation flags can indicate that field values must be before or after the current time. For example, a birthday field must be a past date, and an expiration date field must be a future date. Date validation flags correspond to the past date validation annotation and future date validation annotation in HibernateValidator.
[0092] In this embodiment of the application, the Boolean check flag is used to define the states that a Boolean type field must satisfy.
[0093] In practical implementations, Boolean validation flags can indicate whether a field value must be true or false; for example, an agreement field must be true. Boolean validation flags correspond to the Boolean truth and false validation annotations in Hibernate Validator.
[0094] This application uses non-empty validation flags, length validation flags, numeric validation flags, format validation flags, date validation flags, and Boolean validation flags to construct field validation information. This solves the problem that traditional database triggers require manually writing complex SQL judgment statements for each validation rule. It automatically transforms the rich validation capabilities of the Hibernate Validator framework into rules for database trigger validation. Developers only need to use familiar validation annotations to complete field-level rule definitions without having to learn database trigger syntax, which significantly improves development efficiency and rule expression capabilities.
[0095] Optionally, the step of using the target trigger to verify the data change information and obtaining the data verification result includes: S21, when the database deployment identifier indicates that the field verification information is deployed to the database, a target trigger created for each entity class is used to determine whether the data change information meets the verification conditions corresponding to the field verification information in the entity class. S22, if the data change information meets the verification conditions, determine that the data verification result is passed, and continue to execute the data change operation; S23, if the flexible verification flag indicates an interruption operation when the data change information does not meet the verification conditions, then the data verification result is determined to be a failure, and the data change operation is stopped. S24, if the data change information does not meet the verification conditions, and the flexible verification flag indicates that the operation should not be interrupted, then the data verification result is determined to be a failure, the data change operation is continued, and the verification failure information is recorded according to the log record flag, the log table specified information, and the operation type specified information.
[0096] In this embodiment of the application, when the database deployment identifier indicates that field validation information needs to be deployed to the database, the various target triggers previously created for the target database can be used to validate the data change information, and determine whether the data change information meets the validation conditions corresponding to the field validation information in the entity class.
[0097] In the implementation, each target trigger corresponds to an entity class and is deployed on the database table mapped to that entity class. When a data change operation occurs, the target trigger is automatically triggered. Based on the validation rules defined in the field validation information of the entity class, it checks whether each data change message meets the validation conditions such as non-empty, length range, numerical range, and format requirements.
[0098] In this embodiment of the application, if the data change information meets the verification conditions, the result of the current data verification is determined to be passed.
[0099] In the actual implementation, the target trigger does not intervene after the verification is passed, allowing the data change operation to be executed normally, and the data is successfully written to the database table.
[0100] In this embodiment of the application, if the data change information does not meet the verification conditions, the value of the flexible verification identifier is further checked.
[0101] If the flexible verification flag indicates that the operation is interrupted, the result of this data verification is determined to be a failure, and the data change operation is prevented from continuing.
[0102] In practice, the target trigger will throw an error to the database, rejecting the insert or update operation, and the data will not be written to the database table.
[0103] If the flexible verification flag indicates that the operation will not be interrupted, the result of this data verification is determined to be a failure, but the data change operation is allowed to continue.
[0104] In its implementation, the target trigger further checks the log entry identifier. If the log entry identifier indicates that logging should be recorded, the trigger finds the corresponding log table based on the information specified in the log table, inserts the verification failure information into that table, and simultaneously records the business operation type identified by the operation type identifier. Data change operations continue to execute after logging is complete, and the data is written to the database table.
[0105] Among them, the verification failure information refers to the detailed record when data verification fails, including the table name, field name, data value, operation type, timestamp, and error description.
[0106] This application distinguishes between interrupted and non-interrupted operations when verification fails based on a flexible verification identifier. It records verification failure information according to log record identifiers, log table specified information, and operation type specified information. This solves the problem of traditional database triggers having a single processing method and being unable to flexibly cope with different business scenarios. It realizes refined handling of verification failure data, which can not only reject illegal data to ensure data quality, but also record abnormal data in flexible mode and allow business to continue. At the same time, complete log recording provides a reliable basis for subsequent problem tracking and data analysis.
[0107] Optionally, the step of obtaining the target database currently connected to by the application and determining the target database type of the target database, and determining the target trigger script that matches the target database type from the generated trigger script, includes: S31, Obtain the database type of the target database currently being connected to by the application, and use it as the target database type; S32, from the multiple trigger scripts generated for each entity class, select the trigger script that matches the target database type, and use it as the target trigger script for each entity class.
[0108] In this embodiment of the application, the type of database to which the application is currently connected can be determined first, and this type of database can be used as the target database type.
[0109] In practice, by reading the application's database connection configuration file, information such as the target database's connection address, port, and database name can be obtained, and the type of the target database, such as MySQL, Oracle, or PostgreSQL, can be parsed from it.
[0110] In this embodiment of the application, a trigger script that matches the target database type can be selected from multiple trigger scripts previously generated for each entity class, based on the determined target database type.
[0111] In the actual implementation, the compilation phase generates trigger scripts for each entity class that are adapted to various database types such as MySQL, Oracle, and PostgreSQL. These scripts are stored in the corresponding directory of the deployment package according to the database type.
[0112] For example, when the target database type is determined to be MySQL, a MySQL version script is selected from the script set for each entity class as the target trigger script for that entity class. Similarly, when the target database type is determined to be Oracle, an Oracle version script is selected. This ensures that the script syntax executed subsequently in the target database is fully compatible with the target database.
[0113] This application solves the problem that developers need to manually write multiple sets of scripts due to differences in trigger syntax between different databases by obtaining the target database type and selecting the matching trigger script from multiple pre-generated scripts. It achieves the effect of automatically masking database differences, and developers only need to write the annotation once to adapt to multiple databases, which significantly improves cross-database development efficiency and reduces maintenance costs.
[0114] Optionally, the step of executing the target trigger script against the target database to generate the target trigger includes: S41, when the application starts, the target trigger scripts selected for each entity class and matching the target database type are executed in the target database respectively, and the information of the executed trigger scripts is recorded; S42, after the target trigger script is executed, a corresponding target trigger is generated for each entity class.
[0115] In this embodiment of the application, during the application startup phase, the target trigger script selected for each entity class is executed on the target database.
[0116] In practice, these scripts can be executed automatically using a database migration tool. The database migration tool connects to the target database one by one and executes the target trigger scripts corresponding to each entity class in a predefined order.
[0117] The predefined order refers to the sequence in which the scripts are executed, ensuring that trigger scripts execute according to the correct dependencies. In practice, the execution order of trigger scripts for each entity class can be predefined in the database migration tool's configuration file. This can be done by prefixing the script filenames with numbers or explicitly specifying the execution order in the change log file. The database migration tool will strictly follow this predefined order to execute each trigger script sequentially, ensuring that all scripts execute successfully and that dependencies are correct.
[0118] During execution, the database migration tool records the identification information of each executed script, including script name, execution time, and execution result, and saves this information in a dedicated record table in the database. This ensures that even if the application restarts multiple times, it can accurately identify which scripts have been executed, preventing errors caused by duplicate execution.
[0119] Among them, the information on executed trigger scripts can refer to log data that records the execution history of the script, including script identifier, execution time, execution status, etc., to avoid the script from being executed repeatedly.
[0120] In this embodiment of the application, after all the target trigger scripts have been successfully executed in the target database, the creation statement of each script takes effect, and the corresponding trigger object is actually generated in the target database.
[0121] In the actual implementation, after the target trigger script corresponding to each entity class is executed, a trigger will be created on the database table mapped to that entity class. These triggers are deployed inside the database and are automatically triggered to perform verification when data change operations occur.
[0122] This application solves the problem of traditional deployment methods requiring manual execution of SQL scripts and prone to errors due to repeated execution by automatically executing the target trigger script upon application startup and recording the executed script information, thus achieving automated trigger deployment. Developers do not need to worry about the details of script deployment; the database-level verification mechanism is automatically established upon application startup, significantly improving deployment efficiency and reliability.
[0123] In the specific implementation, refer to Figure 2 The diagram shows a logical schematic of a data verification method provided in an embodiment of this application.
[0124] The first stage is the development and deployment phase, which includes the coding phase, the compilation phase, and the deployment phase.
[0125] During the coding phase, step 201 involves using specified annotations for the specified database object. When writing application code, programmers add a first validation information annotation to the entity class and a second validation information annotation to the fields of the entity class, used to define validation rules and processing strategies.
[0126] During the coding phase, step 202 triggers compilation. After the programmer finishes writing the code, they initiate the compilation process to convert the source code into executable bytecode files.
[0127] During the compilation phase, step 203 involves the annotation processor scanning annotations and generating SQL scripts in a specified format. The annotation processor scans all entity classes annotated with first validation information during compilation, parses the first validation information annotation to obtain validation control information, parses the second validation information annotation to obtain field validation information, and generates trigger scripts based on this information.
[0128] During the compilation phase, step 204 involves generating SQL scripts and packaging them into a JAR (Java Archive) package. The annotation processor generates trigger scripts adapted to different database types for each entity class and packages these scripts into the application's deployment package according to database type.
[0129] During the coding phase, step 205 triggers the pipeline. After code is committed, the continuous integration and continuous deployment pipeline is automatically triggered, initiating the automated build and deployment process.
[0130] During the deployment phase, step 206 involves executing a Liquibase (an open-source database version control tool) script to generate triggers for the corresponding database type. In practice, Liquibase can refer to a database migration tool. When the application starts, the database migration tool automatically executes a trigger script that matches the target database type, creating the corresponding trigger in the target database.
[0131] In the deployment phase, step 207 is "Going live." Once the application has successfully started and is providing services, the deployment process enters the completion phase.
[0132] In the deployment phase, step 208 completes the pipeline. Once the entire continuous integration and continuous deployment pipeline is executed, the new version of the application is officially launched and running.
[0133] The second stage is the runtime phase, which includes user operations and the runtime database.
[0134] User actions, step 209, trigger database changes. Users initiate data addition, modification, or deletion operations through the application interface, which ultimately translate into insert, update, or delete statements in the database.
[0135] During the database runtime phase, step 210 involves invoking the trigger. Once the database detects a data change operation on the target database table, it automatically invokes the target trigger deployed on that table.
[0136] During the database runtime phase, step 211 indicates that the trigger validation passes and no action is taken. The target trigger determines that the data change information meets all field validation conditions, and the validation result is passed. The trigger does not intervene, and the data change operation is executed normally.
[0137] During the database runtime phase, step 212 involves trigger validation failure, writing to the failure log table, and optionally terminating or continuing the process. The target trigger determines that the data change information does not meet the validation conditions and handles it according to the flexible validation flag.
[0138] If the flexible verification flag indicates that the operation is interrupted, the data change operation is terminated.
[0139] If the flexible verification flag indicates that the operation should not be interrupted, the operation is allowed to continue, and the verification failure information is written to the specified log table according to the log record flag, the log table specified information, and the operation type specified information.
[0140] During the database runtime phase, step 213 involves returning a response to the user, which is affected by whether the process is terminated in the configuration.
[0141] Based on the verification results, return a success or failure message to the user.
[0142] Reference Figure 3 The diagram shows a structural schematic of a data verification device according to an embodiment of this application. The device includes: The code acquisition module 301 is used to acquire the application code, which includes a first verification information annotation set for an entity class and a second verification information annotation set for a field in the entity class. The script generation module 302 is used to generate different trigger scripts for different database types based on the first verification information annotation and the second verification information annotation. The script selection module 303 is used to obtain the target database currently connected to by the application and determine the target database type of the target database, and to determine the target trigger script that matches the target database type from the generated trigger scripts. Trigger generation module 304 is used to execute the target trigger script for the target database and generate a target trigger; Data change module 305 is used to obtain data change information in response to a data change operation for the application; The verification result acquisition module 306 is used to verify the data change information using the target trigger and obtain the data verification result.
[0143] Optionally, the script generation module 302 includes: The first parsing submodule is used to parse the first verification information annotation to obtain the verification control information of the entity class; The second parsing submodule is used to parse the second verification information annotation to obtain the field verification information of the field; The script generation submodule is used to generate different trigger scripts for each entity class based on the verification control information and the field verification information, for different database types; wherein, the trigger script corresponding to each entity class is used to generate the trigger corresponding to the entity class after being executed.
[0144] Optionally, the verification control information includes at least one of the following: Database deployment identifier, used to indicate whether the field validation information is deployed to the database; A flexible verification flag is used to indicate whether to interrupt the operation when verification fails; A logging flag is used to indicate whether a log should be logged when a verification fails. The log table specifies information used to record log entries for verification failures. The operation type specification information is used to specify the type of business operation that triggers the verification.
[0145] Optionally, the field validation information includes at least one of the following: The NOT NULL check flag is used to indicate that a field value cannot be empty; Length validation flags are used to indicate the length range of field values; Numerical validation flags are used to indicate the numerical range of field values; Format validation flags are used to indicate the format that a field value must match; Date validation flags are used to indicate the time attribute of a field value; Boolean check flags are used to indicate the Boolean state of a field value.
[0146] Optionally, the verification result acquisition module 306 includes: The first verification submodule is used to determine, when the database deployment identifier indicates that the field verification information is deployed to the database, whether the data change information meets the verification conditions corresponding to the field verification information in the entity class by using the target trigger created for each entity class. The second verification submodule is used to determine that the data verification result is passed when the data change information meets the verification conditions, and to continue to execute the data change operation. The third verification submodule is used to determine that the data verification result is a failure and stop the execution of the data change operation if the flexible verification flag indicates that the operation is interrupted when the data change information does not meet the verification conditions. The fourth verification submodule is used to determine that the data verification result is a failure if the flexible verification flag indicates that the operation should not be interrupted when the data change information does not meet the verification conditions, and to continue to execute the data change operation, and to record the verification failure information according to the log record flag, the log table specified information and the operation type specified information.
[0147] Optionally, the trigger selection module 303 includes: The target type determination submodule is used to obtain the database type of the target database currently connected to by the application, and use it as the target database type; The target script determination submodule is used to select, from the multiple trigger scripts generated for each entity class, the trigger script that matches the target database type, as the target trigger script corresponding to each entity class.
[0148] Optionally, the trigger generation module 304 includes: The target script execution submodule is used to execute, when the application starts, the target trigger script selected for each entity class and matching the target database type in the target database, and to record the executed trigger script information. The target script execution submodule is used to generate a corresponding target trigger for each entity class after the target trigger script has been executed.
[0149] As the apparatus embodiment is basically similar to the method embodiment, it is described in a relatively simple manner. For relevant details, please refer to the description of the method embodiment.
[0150] An embodiment of this application also provides an electronic device, which may include a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the method described above.
[0151] An embodiment of this application also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor, it implements the method described above.
[0152] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.
[0153] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0154] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0155] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0156] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0157] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other modifications and updates to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all modifications and updates falling within the scope of the embodiments of the present application.
[0158] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes the aforementioned element.
[0159] The above provides a detailed description of the data verification method, apparatus, electronic device, and medium. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.
Claims
1. A data verification method, characterized in that, The method includes: Obtain the application code, which contains a first validation information annotation set for an entity class and a second validation information annotation set for a field in the entity class; For different database types, different trigger scripts are generated based on the first verification information annotation and the second verification information annotation respectively; Obtain the target database currently connected to by the application and determine the target database type of the target database; then, determine the target trigger script that matches the target database type from the generated trigger script. Execute the target trigger script on the target database to generate the target trigger; In response to a data change operation for the application, obtain data change information; The target trigger is used to verify the data change information to obtain the data verification result.
2. The method according to claim 1, characterized in that, The steps for generating different trigger scripts based on the first verification information annotation and the second verification information annotation, for different database types, include: Parse the first verification information annotation to obtain the verification control information of the entity class; Parse the second verification information annotation to obtain the field verification information of the field; For different database types, different trigger scripts are generated for each entity class based on the verification control information and the field verification information; wherein, the trigger script corresponding to each entity class is used to generate the trigger corresponding to the entity class after being executed.
3. The method according to claim 2, characterized in that, The verification control information includes at least one of the following: Database deployment identifier, used to indicate whether the field validation information is deployed to the database; A flexible verification flag is used to indicate whether to interrupt the operation when verification fails; A logging flag is used to indicate whether a log should be logged when a verification fails. The log table specifies information used to record log entries for verification failures. The operation type specification information is used to specify the type of business operation that triggers the verification.
4. The method according to claim 2, characterized in that, The field validation information includes at least one of the following: The NOT NULL check flag is used to indicate that a field value cannot be empty; Length validation flags are used to indicate the length range of field values; Numerical validation flags are used to indicate the numerical range of field values; Format validation flags are used to indicate the format that a field value must match; Date validation flags are used to indicate the time attribute of a field value; Boolean check flags are used to indicate the Boolean state of a field value.
5. The method according to claim 3, characterized in that, The step of verifying the data change information using the target trigger to obtain the data verification result includes: When the database deployment identifier indicates that the field validation information is deployed to the database, a target trigger is created for each entity class to determine whether the data change information meets the validation conditions corresponding to the field validation information in the entity class. If the data change information meets the verification conditions, the data verification result is determined to be passed, and the data change operation continues to be executed; If the data change information does not meet the verification conditions, and the flexible verification flag indicates an interruption operation, then the data verification result is determined to be a failure, and the data change operation is stopped. If the data change information does not meet the verification conditions, and the flexible verification flag indicates that the operation should not be interrupted, then the data verification result is determined to be a failure, the data change operation continues, and the verification failure information is recorded according to the log record flag, the log table specified information, and the operation type specified information.
6. The method according to claim 2, characterized in that, The steps of obtaining the target database currently connected to by the application and determining the target database type of the target database, and determining the target trigger script that matches the target database type from the generated trigger script, include: Obtain the database type of the target database currently being connected to by the application, and use it as the target database type; From the multiple trigger scripts generated for each entity class, select the trigger script that matches the target database type and use it as the target trigger script for each entity class.
7. The method according to claim 2, characterized in that, The steps of executing the target trigger script against the target database and generating the target trigger include: When the application starts, a target trigger script that matches the target database type for each entity class is executed in the target database, and the information of the executed trigger scripts is recorded. After the target trigger script is executed, a corresponding target trigger is generated for each entity class.
8. A data verification device, characterized in that, The device includes: The code acquisition module is used to acquire the application's code, which includes a first verification information annotation set for entity classes and a second verification information annotation set for fields in the entity classes. The script generation module is used to generate different trigger scripts for different database types based on the first verification information annotation and the second verification information annotation. The script selection module is used to obtain the target database currently connected to by the application and determine the target database type of the target database, and to determine the target trigger script that matches the target database type from the generated trigger scripts; The trigger generation module is used to execute the target trigger script against the target database and generate a target trigger; The data change module is used to obtain data change information in response to data change operations for the application. The verification result acquisition module is used to verify the data change information using the target trigger and obtain the data verification result.
9. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored on the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the method as described in any one of claims 1-7.
10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the method as described in any one of claims 1-7.