CN115061851A

CN115061851A - Data verification method and device, storage medium and electronic equipment

Info

Publication number: CN115061851A
Application number: CN202210644415.7A
Authority: CN
Inventors: 蔡子辉
Original assignee: Netease Hangzhou Network Co Ltd
Current assignee: Netease Hangzhou Network Co Ltd
Priority date: 2022-06-08
Filing date: 2022-06-08
Publication date: 2022-09-16

Abstract

The disclosure belongs to the technical field of data processing, and relates to a data verification method and device, a storage medium and electronic equipment. The method comprises the following steps: acquiring a data verification request, and determining a field to be verified according to the data verification request; obtaining a custom note of a field to be verified, and obtaining data to be verified in the field to be verified; and carrying out existence verification on the data to be verified by utilizing the user-defined annotation to obtain a data verification result. The method and the device realize the existence check of interactive judgment by combining external data, save the time cost and the development cost for writing check codes, avoid the generation of the code redundancy problem and the code intrusion problem caused by code check, concentrate the check logic on the entity class, cannot cause the dispersion of the check logic, carry out the existence check on the data to be checked of a single field and a field set by the user-defined annotation, enrich the existence check mode, and solve the interactive check requirement of developers in various application scenes.

Description

Data verification method and device, storage medium and electronic equipment

Technical Field

The present disclosure relates to the field of data processing technologies, and in particular, to a data verification method, a data verification apparatus, a computer-readable storage medium, and an electronic device.

Background

Data verification is an indispensable function of the interactive website, and JS (JavaScript, a programming language) verification at the front end can cover most of verification responsibilities. However, in order to avoid the user from bypassing the browser, the server directly requests illegal data from the backend using an HTTP (hypertext Transfer Protocol) tool, and data verification at the server is also necessary. For example, dirty data may be prevented from falling into the database. If an illegal mailbox format appears in the database, the operation and maintenance personnel can be headache.

In general applications, validation (a parameter verification method) can be used for verifying data, which greatly facilitates Web (World Wide Web) development. However, this kind of verification method can only perform logical verification on the content input by the user, and cannot satisfy the requirement of performing interactive judgment in combination with external data. When extra check codes are written to meet the requirement, various problems of service intrusion, code redundancy, non-uniform check codes and the like also occur.

In view of this, there is a need in the art to develop a new data verification method and apparatus.

It is to be noted that the information disclosed in the above background section is only for enhancement of understanding of the background of the present disclosure, and thus may include information that does not constitute prior art known to those of ordinary skill in the art.

Disclosure of Invention

The present disclosure aims to provide a data verification method, a data verification apparatus, a computer-readable storage medium, and an electronic device, so as to overcome the technical problems that interactive judgment cannot be implemented and various code verification defects exist due to limitations of related technologies, at least to a certain extent.

Additional features and advantages of the disclosure will be set forth in the detailed description which follows, or in part will be obvious from the description, or may be learned by practice of the disclosure.

According to a first aspect of the embodiments of the present invention, there is provided a data verification method, including:

acquiring a data verification request, and determining a field to be verified according to the data verification request;

obtaining the custom annotation of the field to be verified, and obtaining the data to be verified in the field to be verified;

and performing existence verification on the data to be verified by using the user-defined annotation to obtain a data verification result.

In an exemplary embodiment of the present invention, the determining a field to be checked according to the data check request includes:

acquiring a request address, and determining a corresponding target method according to the data verification request;

and converting the data verification request to obtain a target object, and determining a field to be verified according to the target method and the target object.

In an exemplary embodiment of the present invention, the determining a field to be checked according to the target method and the target object includes:

when a target annotation exists in the target method, determining that data verification is to be performed on the target object;

acquiring a target field included in the target object and a to-be-executed note corresponding to the target field, wherein the to-be-executed note includes a custom note;

and determining a target field corresponding to the self-defined annotation as a field to be verified, and executing other notes to be executed except the self-defined annotation so as to verify the data of the target field.

In an exemplary embodiment of the invention, the method further comprises:

and when the to-be-executed annotation does not comprise the self-defined annotation, determining not to perform existence check on the to-be-checked data.

In an exemplary embodiment of the invention, the custom annotation comprises: single field annotations and field set annotations.

In an exemplary embodiment of the present invention, the performing presence check on the data to be checked by using the custom annotation to obtain a data check result includes:

determining an entity class corresponding to the field to be verified, and determining that the user-defined note is the single field note and the field to be verified is the single field;

when the data to be verified of the single field is empty, determining that the data verification result of the single field is verification success;

and when the data to be checked of the single field is not empty, performing existence check on the data to be checked of the single field according to the entity class to obtain a data check result.

In an exemplary embodiment of the present invention, the performing presence check on the data to be checked in the single field according to the entity class to obtain a data check result includes:

when the database table name annotation is not acquired according to the entity class, determining that the data verification result of the single field is verification failure;

when the database name annotation is obtained according to the entity class, a database is determined according to the database name annotation, and existence verification is carried out on the data to be verified of the single field according to the database to obtain a data verification result.

In an exemplary embodiment of the present invention, the performing presence check on the data to be checked of the single field according to the database to obtain a data check result includes:

when the data to be verified of the single field exists in the database, determining that the data verification result of the single field is successful;

and when the data to be verified of the single field does not exist in the database, determining that the data verification result of the single field is verification failure.

determining an entity class corresponding to the field to be verified, and determining the custom annotation as the field set annotation and the field to be verified as the field set;

when the data to be verified of the field set is empty, determining that the data verification result of the field set is verification success;

and when the data to be checked in the field set is not empty, performing existence check on the data to be checked in the field set according to the entity class to obtain a data check result.

In an exemplary embodiment of the present invention, the performing presence check on the data to be checked in the field set according to the entity class to obtain a data check result includes:

when the database table name annotation is not acquired according to the entity class, determining that the data verification result of the field set is verification failure;

when database name annotation is obtained according to the entity class, a database is determined according to the database name annotation, and existence verification is carried out on the data to be verified of the field set according to the database to obtain a data verification result.

In an exemplary embodiment of the present invention, the performing presence check on the data to be checked in the field set according to the database to obtain a data check result includes:

requesting a tool class of the database, and acquiring a field template corresponding to the field set by using the tool class;

assembling the field template and the data to be checked of the field set to obtain a query statement;

and executing the query statement to obtain a data checking result of the field set.

In an exemplary embodiment of the present invention, the field template includes: a single field template and a field set template.

In an exemplary embodiment of the present invention, the executing the query statement to obtain the data check result of the field set includes:

if the query statement is obtained through the single field template, executing the query statement to obtain an execution result;

when the execution result is that the database stores the data to be verified in the field set, determining that the data verification result of the field set is successful;

and when the execution result indicates that the database does not have the data to be checked of the field set, determining that the data checking result of the field set is checking failure.

if the query statement is obtained through the field set template, executing the query statement to obtain queried data in the database, and obtaining the queried number of the queried data and the to-be-verified number of the to-be-verified data;

and comparing the queried number with the number to be checked, and obtaining a data checking result of the field set according to a comparison result.

In an exemplary embodiment of the present invention, the obtaining a data verification result of the field set according to the comparison result includes:

when the comparison result is that the number to be verified is larger than the queried number, determining that the data verification result of the field set is verification failure;

and when the comparison result is that the number to be verified is equal to the queried number, determining that the data verification result of the field set is successful.

if the query statement is obtained through the field set template, executing the query statement to obtain queried data in the database;

and comparing the queried statement with the data to be verified, and obtaining a data verification result of the field set according to a comparison result.

when the comparison result is that the data to be verified and the queried data are all the same, determining that the data verification result of the field set is successful;

and when the comparison result is that the data to be verified which is different from the inquired data exists, determining that the data verification result of the field set is verification failure.

In an exemplary embodiment of the present invention, after determining the entity class corresponding to the field to be checked, the method further includes:

and recording the entity class.

In an exemplary embodiment of the present invention, when the data verification result is a verification failure, generating failure prompt data corresponding to the verification failure;

and when the data verification result is verification success, generating prompt success data corresponding to the verification success.

According to a second aspect of the embodiments of the present invention, there is provided a data verification apparatus, including:

the field determining module is configured to acquire a data checking request and determine a field to be checked according to the data checking request;

the annotation acquisition module is configured to acquire a custom annotation of the field to be verified and acquire data to be verified in the field to be verified;

and the data verification module is configured to perform existence verification on the data to be verified by using the custom annotation to obtain a data verification result.

According to a third aspect of embodiments of the present invention, there is provided an electronic apparatus including: a processor and a memory; wherein the memory has stored thereon computer readable instructions which, when executed by the processor, implement the data verification method in any of the exemplary embodiments described above.

According to a fourth aspect of embodiments of the present invention, there is provided a computer-readable storage medium, on which a computer program is stored, the computer program, when executed by a processor, implementing the data verification method in any of the above-described exemplary embodiments.

As can be seen from the foregoing technical solutions, the data verification method, the data verification apparatus, the computer storage medium and the electronic device in the exemplary embodiments of the present disclosure have at least the following advantages and positive effects:

in the method and the device provided by the exemplary embodiment of the disclosure, the existence check of the data to be checked is realized through the custom annotation, the existence check of interactive judgment in combination with the external data is realized, the time cost and the development cost of writing the check code are saved, the generation of the code redundancy problem and the code intrusion problem caused by the code check is avoided, and the check logic is concentrated on the entity class, so that the dispersion of the check logic is avoided. Furthermore, the custom annotation can perform existence check on the data to be checked of a single field and a field set, so that the existence check mode is enriched, and the interactive check requirement of developers in various application scenes is met.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure. It is to be understood that the drawings in the following description are merely exemplary of the disclosure, and that other drawings may be derived from those drawings by one of ordinary skill in the art without the exercise of inventive faculty.

Fig. 1 schematically illustrates a flow chart of a data verification method in an exemplary embodiment of the present disclosure;

fig. 2 schematically illustrates a flowchart of a method for determining a field to be checked according to a data check request in an exemplary embodiment of the present disclosure;

FIG. 3 is a flowchart illustrating a method for determining a field to be checked according to a target method and a target object in an exemplary embodiment of the disclosure;

FIG. 4 schematically illustrates a flow chart of a method of presence verification in an exemplary embodiment of the present disclosure;

FIG. 5 is a flow chart schematically illustrating a method for performing presence check on data to be checked of a single field in an exemplary embodiment of the present disclosure;

FIG. 6 is a flow chart schematically illustrating a method for performing presence check on data to be checked of a single field according to a database in an exemplary embodiment of the present disclosure;

FIG. 7 schematically illustrates a flow chart of another method of presence verification in an exemplary embodiment of the present disclosure;

FIG. 8 is a flow chart diagram schematically illustrating a method for performing presence check on data to be checked of a field set in an exemplary embodiment of the present disclosure;

FIG. 9 is a flow chart diagram schematically illustrating a method for performing presence check on data to be checked of a field set according to a database in an exemplary embodiment of the present disclosure;

FIG. 10 is a schematic flow chart diagram illustrating a method for performing a query statement to obtain a data verification result in an exemplary embodiment of the present disclosure;

FIG. 11 is a schematic flow chart diagram illustrating another method for performing a query statement to obtain a data check result according to an exemplary embodiment of the disclosure;

FIG. 12 schematically illustrates a flow chart of a method of determining a data verification result from a comparison result in an exemplary embodiment of the disclosure;

FIG. 13 is a schematic flow chart diagram illustrating a further method for performing a query statement to obtain a data verification result according to an exemplary embodiment of the disclosure;

FIG. 14 is a schematic flow chart diagram illustrating a method for determining a data verification result from a comparison result in an exemplary embodiment of the present disclosure;

fig. 15 is a flowchart schematically illustrating a method of generating hint information corresponding to data verification results in an exemplary embodiment of the present disclosure;

fig. 16 is a schematic flow chart illustrating a data verification method in the related art in an exemplary embodiment of the present disclosure;

fig. 17 is a schematic flow chart illustrating a data verification method in an application scenario according to an exemplary embodiment of the present disclosure;

fig. 18 is a schematic structural diagram of a data verification apparatus in an exemplary embodiment of the present disclosure;

FIG. 19 schematically illustrates an electronic device for implementing a data verification method in an exemplary embodiment of the present disclosure;

fig. 20 schematically illustrates a computer-readable storage medium for implementing a data verification method in an exemplary embodiment of the present disclosure.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the subject matter of the present disclosure can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and the like. In other instances, well-known technical solutions have not been shown or described in detail to avoid obscuring aspects of the present disclosure.

The terms "a," "an," "the," and "said" are used in this specification to denote the presence of one or more elements/components/parts/etc.; the terms "comprising" and "having" are intended to be inclusive and mean that there may be additional elements/components/etc. other than the listed elements/components/etc.; the terms "first" and "second", etc. are used merely as labels, and are not limiting on the number of their objects.

Furthermore, the drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and thus their repetitive description will be omitted. Some of the block diagrams shown in the figures are functional entities and do not necessarily correspond to physically or logically separate entities.

The data verification is an indispensable function of the interactive website, and the JS verification at the front end can cover most verification responsibilities. However, in order to avoid the user from bypassing the browser and directly requesting illegal data from the backend using the HTTP tool, data verification by the server is also necessary. For example, dirty data may be prevented from falling into the database. If an illegal mailbox format appears in the database, the operation and maintenance personnel can be headache.

In general applications, validation can be used to verify data, which greatly facilitates web development.

Specifically, the JSR303 is a standard, the JSR-349 is an upgraded version of the JSR, some new features are added, and the JSR-349 specifies some verification specifications, i.e. verification annotations, such as @ Null, @ NotNull, @ Pattern, which are located under the javax.

Hibernate validation is the practice of this specification (without tying the hibernate and database orm frameworks together), provides a corresponding implementation, and adds some other verification annotations, such as @ Email, @ Length, @ Range, etc., which are under the org.

In order to provide convenience for developers, universal Spring packages hibernate validity for the second time, and can use Spring validity or hibernate validity when the verified valid bean is displayed. Another feature of Spring validation is that it adds an auto-check in the Spring MVC (Model View Controller) module and packages the check information into a specific class.

When receiving the parameters and binding the parameters, the Spring MVC verifies the object parameters added with the @ Valid/@ Valid annotation.

For example:

@Controller

public class WebController{

@PutMapping("/employee")

public void updateEmployeeInfo(@Valid UpdateEmplyeeRequest request){

// service method

..

}

Wherein, Spring will check the fields of the parameter object for the updateemplyerequest object by using the following comments:

check annotations provided by JSR:

@ Null the annotated element must be Null

The element annotated by @ NotNull must not be null

The annotated element of @ AssertTrue must be true

@ AssertFalse annotated element must be false

The element annotated at @ Min (value) must be a number whose value must be greater than or equal to a specified minimum value

The element annotated at @ Max (value) must be a number whose value must be less than or equal to a specified maximum value

The annotated element of @ DecimalMin (value) must be a number whose value must be greater than or equal to a specified minimum value

The annotated element of @ DecimalMax (value) must be a number whose value must be less than or equal to a specified maximum value

The Size of the annotated element @ Size (max ═ min ═ must be within a specified range

The annotated element of @ Digits must be a number whose value must be within an acceptable range

The annotated element of @ Past must be a Past date

The element annotated by @ Future must be a Future date

The element annotated with @ Pattern (regex ═ flag ═ must conform to the specified regular expression

The check annotation provided by Hibernate Validator:

@ NotBlank (message) — to validate that a string is not null, and must be greater than 0 in length

The annotated element of @ Email must be the Email address

The size of the string annotated with @ Length (min ═ max ═ must be within a specified range

@ NotEmpty annotated string must not be empty

The annotated element of @ Range (min ═ max ═ message ═ must be within the appropriate Range

However, this kind of verification method can only perform logical verification on the content input by the user, and cannot satisfy the requirement of performing interactive judgment in combination with external data.

In the current business, there are many modification/deletion operations, which are related operations that need to transfer the id (Identity document) of a certain database table record. Therefore, id needs to be checked to determine whether the id exists in the table of the database. However, currently existing verification annotations do not meet this requirement.

In the following examples:

for the employee field, the existing annotation can only support the check that the employee field cannot be null at most.

However, it is also necessary to ensure that the Employee id is present in our database Employee table. Therefore, only after the parameter verification of the Spring validity is successful, the following codes are written in the service codes to judge whether the data exist:

obviously, the existing annotations provided are tightly logical checked against the content input by the user, but cannot meet the requirement of interactive judgment in combination with external data.

Therefore, for data presence check of the id field in the example, extra check code needs to be written.

However, this code checking method has many disadvantages.

For example, there is a code intrusion problem because a check code needs to be added before a service code every time a parameter needs to be checked. When a plurality of service methods need to check the id, a plurality of identical check codes appear, which causes code redundancy. In addition, the check logic is realized not only through entity class annotation, but also by means of check codes, so that the problems that the check logic is extremely dispersed and the check codes are not uniform are caused.

In order to solve the problems in the related art, the data verification method is provided. Fig. 1 shows a flow chart of a data verification method, as shown in fig. 1, the data verification method at least includes the following steps:

and S110, acquiring a data verification request, and determining a field to be verified according to the data verification request.

And S120, obtaining the custom annotation of the field to be verified, and obtaining the data to be verified in the field to be verified.

And S130, carrying out existence verification on the data to be verified by using the user-defined annotation to obtain a data verification result.

In the exemplary embodiment of the disclosure, the existence check of the data to be checked is realized through the custom annotation, the existence check of interactive judgment by combining external data is realized, the time cost and the development cost of writing check codes are saved, the code redundancy problem and the code intrusion problem caused by code check are avoided, and the check logic is concentrated on the entity class, so that the dispersion of the check logic is avoided. Furthermore, the custom annotation can perform existence check on the data to be checked of a single field and a field set, so that the existence check mode is enriched, and the interactive check requirement of developers in various application scenes is met.

Each step of the data verification method is explained in detail below.

In step S110, a data verification request is obtained, and a field to be verified is determined according to the data verification request.

In an exemplary embodiment of the present disclosure, the front end may issue a data check request, and call an/employee interface under a xxx domain name through a POST method, for example, @ PostMapping ("/employee"), and the like, which is not limited in this exemplary embodiment.

In the data verification request, a request body issued in JSON (JSON Object Notation) may be:

therefore, the requester of the data check request transmits the fields of the employee id and the name and parameters such as the corresponding data.

In an alternative embodiment, fig. 2 shows a flowchart of a method for determining a field to be checked according to a data check request, and as shown in fig. 2, the method may at least include the following steps: in step S210, a request address is obtained, and a corresponding target method is determined according to the data verification request.

After the front-end passes the parameters, a request address, such as a URL address, for sending the data verification request may be obtained, which is not particularly limited in this exemplary embodiment.

Further, a request address such as a URL (uniform resource locator) address is analyzed through Spring, and a corresponding target method is determined according to the data verification request. For example, the data verification request is a call to the/employee interface, so that it can be determined that the target method corresponding to the interface is an updateemployee info method.

Wherein, the URL is used for identifying the resource; URI (Uniform Resource Identifier) provides a simpler and extensible way to identify resources.

The URL is mainly used to link a web page, a web page component, or a program on the web page, and retrieve a location resource by an access method (a protocol such as HTTP).

URIs are used to define the identity of an item, where the word identifier indicates that a Resource is to be distinguished from other resources regardless of the method used (URL or URN).

URLs are a subset of URIs, but URIs can never be URLs.

URLs specify the type of protocol to be used, whereas URIs do not relate to a protocol specification.

In step S220, the data verification request is converted to obtain a target object, and a field to be verified is determined according to the target method and the target object.

Further, the data verification request and the target method may be bound to each other according to the request address. The binding is to convert the request body of the data check request into an UpdateEmployeeRequest object, i.e., a target object.

The value of the employee field in the target object is assigned 123 and the value of the name field in the target object is assigned minuscule.

In an alternative embodiment, fig. 3 is a flowchart illustrating a method for determining a field to be checked according to a target method and a target object, and as shown in fig. 3, the method may include at least the following steps: in step S310, when the target annotation exists in the target method, it is determined that data verification is to be performed on the target object.

Wherein the target annotation may be the @ Valid annotation.

When the parameter of the target method is added with the target annotation of the @ Valid annotation, Spring determines that data verification needs to be performed on the target object.

In step S320, a target field included in the target object and a to-be-executed note corresponding to the target field are obtained, where the to-be-executed note includes a custom note.

Since the value of the employeeId field in the target object is assigned to 123 and the value of the name field in the target object is assigned to twilight, it can be determined that the target fields are employeeId and name.

Furthermore, it can be verified that the employee id field has two annotations, namely @ NotNull and @ ValidDOId (employee. class), and the name field has an annotation @ NotBlank.

Therefore, it may be determined that the to-be-executed annotation corresponding to the target field may include @ NotNull, @ validdodid, and @ NotBlank.

Where the @ ValidDOId annotation is a custom annotation, not an annotation already present in Spring.

In step S330, the target field corresponding to the custom annotation is determined as the field to be verified, and other annotations to be executed except for the custom annotation are executed to perform data verification on the target field.

Since the @ ValidDOId annotation is determined to be a custom annotation and the @ ValidDOId annotation is an annotation of the target field employeid, the target field may also be a field to be checked for which the @ ValidDOId annotation is executed.

In addition to the @ ValidDOId annotation, other @ NotNull annotations and @ NotBlank annotations may be performed at this time, logic to perform data checks on the corresponding target fields having been performed. Wherein, the @ NotNull annotation and the @ NotBlank annotation both indicate that the corresponding target field is required, and the @ NotBlank annotation restricts the string length of the target field to be larger than 0.

In an alternative embodiment, when the custom annotation is not included in the annotation to be executed, it is determined that the data to be checked is not subjected to the presence check.

When it is determined in step S320 that the to-be-executed annotation does not include the custom annotation, for example, @ ValidDOId, it may be determined that the to-be-executed annotation executed on the target field is only the annotation originally included in Spring, and therefore, the corresponding to-be-executed annotation is executed to implement the data verification on the target field, and it is not necessary to determine the to-be-verified field and perform the existence verification on the data of the to-be-verified field through the custom annotation.

In the exemplary embodiment, the field to be checked corresponding to the existence check to be performed can be determined through the data check request sent by the front end, the determination mode is simple and accurate, and field support is provided for the existence check.

In step S120, a custom annotation of the field to be verified is obtained, and data to be verified in the field to be verified is obtained.

In an exemplary embodiment of the present disclosure, after determining the field to be checked, the custom annotation determined in step S320 may be obtained.

In an alternative embodiment, the custom annotation comprises: single field annotations and field set annotations.

Where a single field annotation may be the @ ValidDOId annotation and a field set annotation may be the @ ValidDOIds annotation. The @ ValidDOId annotation may be an annotation class that enables presence checking of a single field, and the @ ValidDOIds annotation may be an annotation class that enables presence checking of a set of fields.

It should be noted that, when the target field is the @ valid annotation, the corresponding single field annotation and field set annotation may also be named by other names, which is not particularly limited in this exemplary embodiment.

Further, the data to be verified stored in the field to be verified, such as 123 and xiaoming, may also be determined according to the field to be verified determined in step S330.

In step S130, performing existence check on the data to be checked by using the custom annotation to obtain a data check result.

In the exemplary embodiment of the present disclosure, after the custom annotation and the data to be verified are obtained, the presence verification may be performed on the data to be verified by using the custom annotation, so as to obtain a corresponding data verification result.

In an alternative embodiment, fig. 4 shows a flow diagram of a method for presence verification, which, as shown in fig. 4, may include at least the following steps: in step S410, the entity class corresponding to the field to be verified is determined, and the custom note is determined as a single field note and the field to be verified is determined as a single field.

By Class <? Value () can determine the entity class corresponding to the field to be checked.

Further, it can be determined that the custom comment is a single field comment by class DOIdValidator requirements construction < ValidDOId, Long >, therefore, the field to be checked is a single field, and at this time, the presence check is performed on the data to be checked in the single field by the single field comment.

In step S420, when the data to be checked in a single field is empty, it is determined that the data check result in the single field is a check success.

In particular, by

if(Objects.isNull(value)){

return true；

}

A determination may be made as to whether the data to be checked for a single field is empty.

And when the data to be checked in the single field is empty, determining that the data check result in the single field is successful.

In step S430, when the data to be checked in a single field is not empty, performing presence check on the data to be checked in the single field according to the entity class to obtain a data check result.

Correspondingly, when it is determined through the code in step S420 that the data to be checked in the single field is not empty, it is further necessary to perform presence check on the data to be checked in the single field according to the entity class.

In an alternative embodiment, fig. 5 shows a flowchart of a method for performing presence check on data to be checked in a single field, and as shown in fig. 5, the method may at least include the following steps: in step S510, when the database table name annotation is not obtained according to the entity class, it is determined that the data verification result of the single field is verification failure.

Specifically, the database table name annotation of @ TableName on the entity class is obtained by TableName association ═ cs.

And when the @ TableName annotation cannot be acquired according to the entity class, determining that the data verification result of the data to be verified of the single field is verification failure, and throwing out an exception.

In step S520, when the database table name annotation is obtained according to the entity class, the database is determined according to the database table name annotation, and the existence check is performed on the data to be checked in a single field according to the database, so as to obtain a data check result.

Specifically, the database table name annotation @ TableName on the entity class is obtained through TableName annotation ═ cls.

When the @ TableName annotation can be obtained according to the entity class, the corresponding database table name is marked in the @ TableName annotation, so that the corresponding database can be determined according to the database table name.

In an alternative embodiment, fig. 6 is a flowchart illustrating a method for performing presence check on data to be checked in a single field according to a database, where as shown in fig. 6, the method may include at least the following steps: in step S610, when there is data to be verified in a single field in the database, it is determined that the data verification result is a verification success.

Specifically, whether the data to be checked in a single field exists is judged by requesting a database through return jdbchunk.

When the data to be verified of a single field exists in the database, the data verification result is determined to be successful, namely the data to be verified exists in the database.

In step S620, when there is no data to be checked in a single field in the database, it is determined that the data check result is a check failure.

Specifically, whether the data to be checked in a single field exists or not is judged by requesting a database through return jdbc utility.

When the data to be verified of a single field does not exist in the database, determining that the data verification result is verification failure, namely that the data to be verified does not exist in the database.

Based on this, the implementation of the presence check on the data to be checked through the custom annotation, which is the single field annotation, may be as follows:

in the exemplary embodiment, the existence check of the data to be checked of a single field is realized through the user-defined comment, the existence check can be realized only by calling the corresponding single field comment, the code writing is not needed, the code redundancy problem and the code intrusion problem caused by the code check are solved, and the check logic is not scattered on an entity class and the check code because of the code check.

Fig. 7 shows a flow diagram of another method for presence verification, which, as shown in fig. 7, may include at least the following steps: in step S710, the entity class corresponding to the field to be verified is determined, and the custom annotation is determined as a field set annotation and the field to be verified is determined as a field set.

In step S410 and step S710, after the entity class corresponding to the check field is determined, the data may be initialized.

In an alternative embodiment, the entity class is recorded.

Therefore, after the entity class corresponding to the field to be checked is determined, the data can be initialized by recording the entity class.

Furthermore, it can be determined that the custom annotation is a field set annotation, that is, validdoid, through class Collection validater requirements constrainting va-iidator < validdoid, Collection < Long >, therefore, the field to be verified is a field corresponding to multiple data to be verified, and at this time, existence verification is performed on multiple data to be verified in the field to be verified through the field set annotation.

In step S720, when the data to be checked in the field set is empty, it is determined that the data check result in the field set is a check success.

Specifically, the method comprises the following steps:

if(CollUtil.isEmpty(value)){

return true；

}

it may be determined whether the data to be checked of the field set is empty.

And when the data to be checked in the field set is empty, determining that the data check result of the single field is successful.

In step S730, when the data to be checked in the field set is not empty, performing presence check on the data to be checked in the field set according to the entity class to obtain a data check result.

Correspondingly, when it is determined through the code in step S720 that the data to be checked in the field set is not empty, it is further necessary to perform existence check on the data to be checked in the field set according to the entity class.

In an alternative embodiment, fig. 8 shows a flowchart of a method for performing presence check on data to be checked of a field set, and as shown in fig. 8, the method may include at least the following steps: in step S810, when the database table name annotation is not obtained according to the entity class, it is determined that the data verification result of the field set is verification failure.

And when the @ TableName annotation cannot be acquired according to the entity class, determining that the data verification result of the data to be verified in the field set is verification failure, and throwing out an exception.

In step S820, when the database table name annotation is obtained according to the entity class, the database is determined according to the database table name annotation, and the existence check is performed on the data to be checked in the field set according to the database to obtain the data check result.

In an alternative embodiment, fig. 9 is a flowchart illustrating a method for performing presence check on data to be checked of a field set according to a database, where as shown in fig. 9, the method may include at least the following steps: in step S910, a tool class of the database is requested, and a field template corresponding to the field set is obtained by using the tool class.

The tool class is a class with a large use of the database, is equivalent to a tool, and can realize multiple functions of addition, deletion, modification, searching and the like. The management system can be directly used for calling when the management system is created. If fully utilized, the code will be more compact.

Thus, a tool class requesting the database can obtain a field template corresponding to a field set.

In an alternative embodiment, the field template comprises: a single field template and a field set template.

The field set template may be a template for querying a field set by using a single field in the field set, and the field set template may be a template for querying a field set as a whole.

For example, the single field template may be SELECT id from% s where id ═ d, and the field set template may be SELECT id from% s where id in (% s), which is not particularly limited in the present exemplary embodiment.

In step S920, the field template and the data to be checked in the field set are assembled to obtain the query statement.

After the field template is obtained, the data to be checked of the field set and the field template may be assembled to obtain a corresponding query statement.

For example, the query statement assembled according to the single field template may be a select id from employee where id is 1; the query statement assembled according to the field set template may be a select id from employee where id in (1,2, 3).

In step S930, the query statement is executed to obtain a data check result of the field set.

In an alternative embodiment, fig. 10 is a flowchart illustrating a method for obtaining a data verification result by executing a query statement, and as shown in fig. 10, the method may include at least the following steps: in step S1010, if the query statement is obtained through the single field template, the query statement is executed to obtain an execution result.

When the query statement is obtained by assembling a single field template, the query statement can be directly executed, and whether the data to be checked of the field set in the query statement exists in the database or not is judged to obtain a query result.

Specifically, the execution of the query statement may be implemented in this manner:

String sql＝String.format(VALID_ID_SQL_TEMPLATE,tableName,id)；

return jdbcTemplate.query(sql,ResultSet::next)；

in step S1020, when the execution result is that the database stores the data to be verified in the field set, it is determined that the data verification result of the field set is verification success.

When the execution result of the query statement is that the data to be verified of the field set exists in the database, the data verification result of the field set is that verification is successful.

In step S1030, when the execution result is that the database does not have the data to be verified of the field set, it is determined that the data verification result of the field set is a verification failure.

When the execution result of the query statement is that the data to be verified of the field set does not exist in the database, the data verification result of the field set is verification failure.

In the exemplary embodiment, a method for executing a query statement obtained by a single field template to determine a data verification result is provided, which enriches existing verification modes of field set annotation from the verification perspective of a single field in a field set, further solves the disadvantages of code redundancy, code intrusion and the like caused by code verification, and enriches application scenarios for realizing existing verification through annotation.

In an alternative embodiment, fig. 11 is a flowchart illustrating another method for obtaining a data verification result by executing a query statement, and as shown in fig. 11, the method may include at least the following steps: in step S1110, if the query statement is obtained through the field set template, the query statement is executed to obtain queried data in the database, and a queried number of the queried data and a to-be-verified number of the to-be-verified data are obtained.

When the query statement is obtained by assembling the field set template, the query statement can be directly executed to obtain queried data which can be queried in the database according to the query statement.

Further, the queried number of the queried data can be obtained, and the queried number represents the number of data which can be queried in the database according to the data to be verified.

And the number to be verified of the data to be verified can be counted, wherein the number to be verified is the sum of the number of the data to be verified.

In step S1120, the queried number and the to-be-verified number are compared, and a data verification result of the field set is obtained according to the comparison result.

After the queried number and the to-be-verified number are obtained, the queried number and the to-be-verified number can be compared to obtain a comparison result.

In an alternative embodiment, fig. 12 is a flowchart illustrating a method for determining a data verification result according to the comparison result, and as shown in fig. 12, the method may include at least the following steps: in step S1210, when the comparison result is that the number to be checked is greater than the queried number, it is determined that the data check result of the field set is a check failure.

For example, when the number to be verified is 3 and the number of queried data is 2, it indicates that the number of data to be verified that can be queried in the database is less than the number to be verified, and therefore, there is data that is not found in the database and cannot be queried in the data to be verified. Then, the data verification result of the field set at this time is verification failure.

In step S1220, when the comparison result is that the number to be verified is equal to the queried number, it is determined that the data verification result of the field set is verification success.

For example, when the number to be verified is 3 and the number queried is 3, it indicates that the number of data to be verified that can be queried in the database is equal to the number to be verified, and therefore, all data to be verified exist in the database, and there is no data that cannot be queried. Then the data verification result of the field set at this time is verification success.

In the exemplary embodiment, a method for executing a query statement obtained by a field set template to determine a data verification result is provided, which enriches existing verification manners of field set annotation from the perspective of performing overall verification on a field set, further solves the disadvantages of code redundancy and code intrusion caused by code verification, and enriches application scenarios for realizing existing verification through annotation.

In an alternative embodiment, fig. 13 is a flowchart illustrating a further method for performing a query statement to obtain a data verification result, where as shown in fig. 13, the method at least includes the following steps: in step S1310, if the query statement is obtained through the field set template, the query statement is executed to obtain queried data in the database.

In step S1320, the queried statement is compared with the data to be verified, and a data verification result of the field set is obtained according to the comparison result.

Furthermore, the queried data obtained by executing the query statement can be compared with the data to be verified to obtain a comparison result.

The method for comparing the queried data with the data to be verified may be to determine whether the queried data is the same as the data to be verified.

In an alternative embodiment, fig. 14 is a flowchart illustrating a method for determining a data verification result according to the comparison result, and as shown in fig. 14, the method may include at least the following steps: in step S1410, when the comparison result indicates that the data to be verified is the same as the queried data, it is determined that the data verification result of the field set is successful.

For example, when the data to be verified is {1,2,3} and the queried data is also {1,2,3}, it indicates that the data to be verified and the queried data are all the same, so that the data to be verified can be queried in the database identically, and at this time, it is determined that the data verification result is successful.

In step S1420, when the comparison result is that there is data to be verified that is different from the queried data, it is determined that the data verification result of the field set is verification failure.

For example, when the data to be verified is {1,2,3} and the queried data is also {1,2}, then {3} in the data to be verified cannot be queried for the same data in the database, and therefore there is data {3} in the data to be verified that is different from the queried data, and the data verification result is a verification failure.

In the exemplary embodiment, another method for executing the query statement obtained by the field set template to determine the data verification result is provided, and an existence verification manner of the field set annotation is enriched from another perspective of performing overall verification on the field set, so that the disadvantages of code redundancy, code intrusion and the like caused by code verification are further solved, and an application scenario for realizing existence verification through annotation is enriched.

Based on this, the implementation of performing presence check on data to be checked through the custom annotation, i.e. the field set annotation, may be as follows:

after the data verification result is determined, corresponding prompt information can be generated according to different data verification results, so that developers can conveniently and accurately master the data verification result.

In an alternative embodiment, fig. 15 is a flowchart illustrating a method for generating prompt information corresponding to a data verification result, where as shown in fig. 15, the method may include at least the following steps: in step S1510, when the data verification result is a verification failure, failure-prompted data corresponding to the verification failure is generated.

When the data verification result is that the single field verification fails or the field set verification fails, failure-prompting data corresponding to the data verification result with the verification failure can be generated.

For example, the failure-to-prompt data may be "database entity does not exist", or other data, which is not limited in the present exemplary embodiment.

In step S1520, when the data verification result is verification success, prompt success data corresponding to the verification success is generated.

When the data verification result is successful in either single field verification or field set verification, the success-prompting data corresponding to the data verification result which is successfully verified can be generated.

The data verification method in the embodiment of the present disclosure is described in detail below with reference to an application scenario.

Fig. 16 is a flow chart illustrating a data checking method in the related art, and as shown in fig. 16, there are many modification/deletion operations in the current business, which are related operations that need to transfer the id of a certain database table record. Therefore, id needs to be checked to determine whether the id exists in the table of the database. However, currently existing verification annotations do not meet this requirement.

In the following examples:

However, this code checking method has many disadvantages.

Fig. 17 is a schematic flowchart illustrating a data verification method in an application scenario, and as shown in fig. 17, in step S1710, the front end passes parameters.

The front end may send a data check request, and call an/employee interface under the xxx domain name through a POST method, for example, @ PostMapping ("/employee"), and the like, which is not limited in this exemplary embodiment.

In the data verification request, the request body issued by JSON may be:

In step S1720, Spring MVC performs parameter binding.

And acquiring a request address, and determining a corresponding target method according to the data verification request.

After the front-end passes the parameters, a request address, such as a URL address, for sending the data verification request may be obtained, which is not limited in this exemplary embodiment.

Furthermore, request addresses such as URL addresses are analyzed through Spring, and corresponding target methods are determined according to the data verification requests. For example, the data verification request calls the/employee interface, so that it can be determined that the target method corresponding to the interface is the updateemployee info method.

And converting the data verification request to obtain a target object.

Further, the data verification request and the target method may be bound to each other according to the request address. The binding is to convert the requestor of the data check request into an UpdateEmployeeRequest object, i.e., a target object.

The value of the employeeId field in the target object is assigned as 123, and the value of the name field in the target object is assigned as Xiaoming.

In step S1730, whether or not a check is required.

When the target annotation exists in the target method, determining that data verification is to be performed on the target object.

Wherein the target annotation may be the @ Valid annotation.

In step S1740, Spring validation performs parameter verification.

And acquiring a target field included in the target object and a to-be-executed note corresponding to the target field, wherein the to-be-executed note includes a custom note.

Therefore, it can be determined that the to-be-executed annotation corresponding to the target field may include @ NotNull, @ ValidDOId, and @ NotBlank.

And determining a target field corresponding to the custom note as a field to be verified, and executing other notes to be executed except the custom note so as to perform data verification on the target field.

Since the @ ValidDOId annotation is determined to be a custom annotation, and the @ ValidDOId annotation is an annotation of an employyeeld, which is a target field, the target field may also be a field to be checked for executing the @ ValidDOId annotation.

In addition to the @ ValidDOId annotation, other @ NotNull annotations and @ NotBlank annotations may be performed at this point, with the logic for data checking of the corresponding target field having been performed. Wherein, the @ NotNull annotation and the @ NotBlank annotation both indicate that the corresponding target field is required, and the @ NotBlank annotation restricts the string length of the target field to be larger than 0.

In addition, when the self-defined annotation is not included in the annotation to be executed, the data to be checked is determined not to be subjected to the existence check.

When it is determined that the to-be-executed annotation does not include a custom annotation, for example, @ ValidDOId, it may be determined that the to-be-executed annotation executed on the target field is only the annotation originally included in Spring, and therefore, the corresponding to-be-executed annotation is executed to implement data verification on the target field, and it is not necessary to determine the to-be-verified field and perform presence verification on the data of the to-be-verified field through the custom annotation.

After determining the field to be checked, the determined custom annotation may be obtained.

Wherein the custom annotation comprises: single field annotations and field set annotations.

In particular, the single field annotation may be the @ ValidDOId annotation and the field set annotation may be the @ ValidDOIds annotation. The @ ValidDOId annotation may be an annotation class that enables presence checking of a single field, and the @ ValidDOIds annotation may be an annotation class that enables presence checking of a set of fields.

Further, the data to be checked stored in the field to be checked, such as 123 and xiaoming, may also be determined according to the determined field to be checked.

After the user-defined annotation and the data to be verified are obtained, the user-defined annotation can be used for performing existence verification on the data to be verified so as to obtain a corresponding data verification result.

And determining an entity class corresponding to the field to be verified, and determining that the self-defined annotation is a single field annotation and the field to be verified is a single field.

For example, the entity class may be DataObject:

And when the data to be checked of the single field is empty, determining that the data check result of the single field is successful.

In particular, by

if(Objects.isNull(value)){

return true；

}

Correspondingly, when it is determined that the data to be checked in a single field is not empty, the data to be checked in the single field needs to be further subjected to existence check according to the entity class.

And when the database table name annotation is not acquired according to the entity class, determining that the data verification result of the single field is verification failure.

When the database name annotation is obtained according to the entity class, the database is determined according to the database name annotation, and the existence verification is carried out on the data to be verified of a single field according to the database to obtain a data verification result.

Wherein the database table may be:

CREATE TABLE`pm_employee`(

'id' big (20) NOT NULL COMMENT 'master key',

"name" varchar (64) NOT NULL COMMENT 'name',

PRIMARY KEY(`id`)

) ENGINE ═ InnoDB defilt CHARSET ═ utf8mb4 common ═ employee table';

and when the data to be verified of a single field exists in the database, determining that the data verification result is successful.

And when the data to be verified of a single field does not exist in the database, determining that the data verification result is verification failure.

and determining an entity class corresponding to the field to be verified, and determining the self-defined annotation as a field set annotation and the field to be verified as a field set.

It should be noted that after determining the entity class corresponding to the check field, the data may also be initialized. In particular, it may be a record entity class.

Furthermore, it can be determined that the custom annotation is a field set annotation through class Collection validator instances construction requirements for variable data < valid doids, Collection < Long > >, so that the field to be verified is a field corresponding to a plurality of data to be verified, and at this time, existence verification is performed on the plurality of data to be verified in the field to be verified through the field set annotation.

And when the data to be checked in the field set is empty, determining that the data checking result of the field set is successful.

Specifically, the method comprises the following steps:

if(CollUtil.isEmpty(value)){

return true；

}

it may be determined whether the data to be checked of the field set is empty.

Correspondingly, when it is determined that the data to be checked in the field set is not empty, the data to be checked in the field set needs to be further subjected to existence check according to the entity class.

And when the database table name annotation is not acquired according to the entity class, determining that the data verification result of the field set is verification failure.

When the database table name annotation is obtained according to the entity class, the database is determined according to the database table name annotation, and the existence verification is carried out on the data to be verified of the field set according to the database to obtain a data verification result.

And requesting a tool class of the database, and acquiring a field template corresponding to the field set by using the tool class.

The tool class is a class with a large use place of the database, is equivalent to a tool, and can realize various functions such as addition, deletion, modification, check and the like. The management system can be directly used for calling when the management system is created. If fully utilized, the code will be more compact.

Wherein, the field template includes: a single field template and a field set template.

Specifically, the single field template may be a template for performing a query in a manner of a single field in the field set, and the field set template may be a template for performing a query by regarding the field set as a whole.

And assembling the field template and the data to be checked of the field set to obtain the query statement.

And if the query statement is obtained through the single field template, executing the query statement to obtain an execution result.

String sql＝String.format(VALID_ID_SQL_TEMPLATE,tableName,id)；

return jdbcTemplate.query(sql,ResultSet::next)；

and when the execution result is the data to be verified, which is stored in the field set by the database, determining that the data verification result of the field set is successful.

And when the execution result is that the database does not have the data to be checked of the field set, determining that the data checking result of the field set is checking failure.

When the execution result of the query statement is that the data to be checked of the field set does not exist in the database, the data checking result of the field set is checking failure.

And if the query statement is obtained through the field set template, executing the query statement to obtain queried data in the database, and obtaining the queried quantity of the queried data and the to-be-verified quantity of the to-be-verified data.

And, the number to be verified of the data to be verified can be counted, and the number to be verified is the sum of the number of the data to be verified.

And comparing the inquired quantity with the quantity to be checked, and obtaining a data checking result of the field set according to the comparison result.

And when the comparison result is that the number to be verified is larger than the number queried, determining that the data verification result of the field set is verification failure.

For example, when the number to be verified is 3 and the number queried is 2, it indicates that the number of data to be verified that can be queried in the database is not enough to be verified, and therefore, there are data to be verified that are not found in the database and therefore cannot be queried. Then, the data verification result of the field set at this time is verification failure.

And when the comparison result is that the number to be verified is equal to the number queried, determining that the data verification result of the field set is successful.

And if the query statement is obtained through the field set template, executing the query statement to obtain the queried data in the database.

And comparing the queried statement with the data to be verified, and obtaining a data verification result of the field set according to the comparison result.

And when the comparison result is that the data to be verified is the same as the queried data, determining that the data verification result of the field set is successful.

And when the comparison result is that the data to be checked different from the inquired data exists, determining that the data check result of the field set is check failure.

Based on this, the implementation manner of performing presence check on the data to be checked through the custom annotation, i.e. the field set annotation, may be as follows:

And when the data verification result is verification failure, generating prompt failure data corresponding to the verification failure.

And when the data verification result is successful verification, generating prompt success data corresponding to successful verification.

In step S1750, the business logic.

Specifically, the controller classes of the receiving parameters and the processing service are as follows:

@PostMapping("/employee")

public void updateEmployeeInfo(@Valid@RequestBody UpdateEmplyeeRequest request){

// service code.

...

}

Therefore, the corresponding service code can be continuously executed if the check is successful.

Wherein, the entity class obtained by converting the parameters from the front-end infection is UpdateEmplyeRequest, and the entity class is as follows:

in step S1760, the return result ends.

And when the data verification result is verification failure, directly returning the result of the verification failure without executing the service logic.

In the data verification method in the exemplary embodiment of the disclosure, existence verification is performed on data to be verified through the custom annotation, existence verification performed by combining external data for interactive judgment is realized, time cost and development cost for writing verification codes are saved, the generation of code redundancy and code intrusion problems caused by code verification is avoided, and verification logic is concentrated on entity classes, so that the dispersion of verification logic is avoided. Furthermore, the custom annotation can perform existence check on the data to be checked of a single field and a field set, so that the existence check mode is enriched, and the interactive check requirement of developers in various application scenes is met.

In addition, in an exemplary embodiment of the present disclosure, a data verification apparatus is also provided. Fig. 18 shows a schematic structural diagram of a data verification apparatus, and as shown in fig. 18, the data verification apparatus 1800 may include: a field determination module 1810, an annotation acquisition module 1820, and a data verification module 1830. Wherein:

a field determining module 1810 configured to obtain a data check request, and determine a field to be checked according to the data check request;

the annotation acquisition module 1820 is configured to acquire a custom annotation of the field to be verified, and acquire data to be verified in the field to be verified;

and a data verification module 1830 configured to perform existence verification on the data to be verified by using the custom annotation to obtain a data verification result.

In an exemplary embodiment of the invention, the method further comprises:

when database name annotation is obtained according to the entity class, a database is determined according to the database name annotation, and existence verification is carried out on the data to be verified of the single field according to the database to obtain a data verification result.

when the comparison result is that the number to be checked is larger than the queried number, determining that the data check result of the field set is check failure;

and recording the entity class.

In an exemplary embodiment of the present invention, when the data verification result is a verification failure, generating failure-prompting data corresponding to the verification failure;

The details of the data verification apparatus 1800 have already been described in detail in the corresponding data verification method, and therefore are not described herein again.

It should be noted that although several modules or units of data validation apparatus 1800 are mentioned in the above detailed description, such partitioning is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the present disclosure. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.

In addition, in an exemplary embodiment of the present disclosure, an electronic device capable of implementing the above method is also provided.

An electronic device 1900 according to such an embodiment of the invention is described below with reference to fig. 19. The electronic device 1900 shown in fig. 19 is only an example, and should not bring any limitation to the functions and the scope of the use of the embodiments of the present invention.

As shown in fig. 19, electronic device 1900 takes the form of a general-purpose computing device. Components of electronic device 1900 may include, but are not limited to: the at least one processing unit 1910, the at least one memory unit 1920, a bus 1930 connecting different system components (including the memory unit 1920 and the processing unit 1910), and a display unit 1940.

Wherein the storage unit stores program code that is executable by the processing unit 1910 to cause the processing unit 1910 to perform steps according to various exemplary embodiments of the present invention described in the "exemplary methods" section above of the present specification.

The storage 1920 may include readable media in the form of volatile memory units, such as a random access memory unit (RAM)1921 and/or a cache memory unit 1922, and may further include a read-only memory unit (ROM) 1923.

The storage unit 1920 may also include a program/utility 1924 having a set (at least one) of program modules 1925, such program modules 1925 including, but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may comprise an implementation of a network environment.

Bus 1930 can be one or more of several types of bus structures including a memory unit bus or memory unit controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

The electronic device 1900 may also communicate with one or more external devices 2100 (e.g., keyboard, pointing device, Bluetooth device, etc.), with one or more devices that enable a user to interact with the electronic device 1900, and/or with any devices (e.g., router, modem, etc.) that enable the electronic device 1900 to communicate with one or more other computing devices. Such communication can occur via input/output (I/O) interface 1950. Also, electronic device 1900 may communicate with one or more networks (e.g., a Local Area Network (LAN), a Wide Area Network (WAN), and/or a public network, such as the internet) via network adapter 1960. As shown, the network adapter 1960 communicates with the other modules of the electronic device 1900 via a bus 1930. It should be appreciated that although not shown, other hardware and/or software modules may be used in conjunction with electronic device 1900, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, among others.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

In an exemplary embodiment of the present disclosure, there is also provided a computer-readable storage medium having stored thereon a program product capable of implementing the above-described method of the present specification. In some possible embodiments, aspects of the invention may also be implemented in the form of a program product comprising program code means for causing a terminal device to carry out the steps according to various exemplary embodiments of the invention described in the above-mentioned "exemplary methods" section of the present description, when said program product is run on the terminal device.

Referring to fig. 20, a program product 2000 for implementing the above method according to an embodiment of the present invention is described, which may employ a portable compact disc read only memory (CD-ROM) and include program code, and may be run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited in this regard and, in the present document, a readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

A computer readable signal medium may include a propagated data signal with readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A readable signal medium may also be any readable medium that is not a readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, C + + or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, as a stand-alone software package, partly on the user's computing device and partly on a remote computing device, or entirely on the remote computing device or server. In situations involving remote computing devices, the remote computing devices may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to external computing devices (e.g., through the internet using an internet service provider).

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

Claims

1. A method for data verification, the method comprising:

obtaining the user-defined note of the field to be verified, and obtaining the data to be verified in the field to be verified;

2. The data verification method of claim 1, wherein the determining a field to be verified according to the data verification request comprises:

3. The data verification method of claim 2, wherein the determining a field to be verified according to the target method and the target object comprises:

4. The data verification method of claim 3, further comprising:

5. The data verification method of claim 1, wherein the custom annotation comprises: single field annotations and field set annotations.

6. The data verification method of claim 5, wherein the performing presence verification on the data to be verified by using the custom annotation to obtain a data verification result comprises:

7. The data verification method of claim 6, wherein performing presence verification on the data to be verified in the single field according to the entity class to obtain a data verification result comprises:

8. The data verification method of claim 7, wherein the performing presence verification on the data to be verified of the single field according to the database to obtain a data verification result comprises:

and when the data to be checked of the single field does not exist in the database, determining that the data checking result of the single field is checking failure.

9. The data verification method of claim 5, wherein the performing presence verification on the data to be verified by using the custom annotation to obtain a data verification result comprises:

10. The data verification method of claim 9, wherein performing presence verification on the data to be verified in the field set according to the entity class to obtain a data verification result includes:

11. The data verification method of claim 10, wherein performing presence verification on the data to be verified in the field set according to the database to obtain a data verification result includes:

12. The data verification method of claim 11, wherein the field template comprises: a single field template and a field set template.

13. The data verification method of claim 12, wherein the executing the query statement to obtain the data verification result for the set of fields comprises:

14. The data verification method of claim 12, wherein the executing the query statement to obtain the data verification result for the set of fields comprises:

if the query statement is obtained through the field set template, executing the query statement to obtain queried data in the database, and obtaining the queried number of the queried data and the to-be-checked number of the to-be-checked data;

15. The data verification method of claim 14, wherein obtaining the data verification result of the field set according to the comparison result comprises:

and when the comparison result is that the number to be verified is equal to the queried number, determining that the data verification result of the field set is verification success.

16. The data verification method of claim 12, wherein the executing the query statement to obtain the data verification result for the set of fields comprises:

17. The data verification method of claim 16, wherein obtaining the data verification result of the field set according to the comparison result comprises:

18. The data verification method according to claim 6 or 9, wherein after the determining the entity class corresponding to the field to be verified, the method further comprises:

and recording the entity class.

19. The data verification method of claim 1, further comprising:

when the data verification result is verification failure, generating prompt failure data corresponding to the verification failure;

20. A data verification apparatus, comprising:

21. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the data verification method of any one of claims 1 to 19.

22. An electronic device, comprising:

a processor;

a memory for storing executable instructions of the processor;

wherein the processor is configured to perform the data verification method of any one of claims 1-19 via execution of the executable instructions.