CN116362230A - Parameter verification method, device and computer equipment storable medium - Google Patents
Parameter verification method, device and computer equipment storable medium Download PDFInfo
- Publication number
- CN116362230A CN116362230A CN202310317267.2A CN202310317267A CN116362230A CN 116362230 A CN116362230 A CN 116362230A CN 202310317267 A CN202310317267 A CN 202310317267A CN 116362230 A CN116362230 A CN 116362230A
- Authority
- CN
- China
- Prior art keywords
- parameter
- condition
- condition parameters
- target object
- verification
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000012795 verification Methods 0.000 title claims abstract description 151
- 238000000034 method Methods 0.000 title claims abstract description 69
- 230000002159 abnormal effect Effects 0.000 claims abstract description 94
- 238000004590 computer program Methods 0.000 claims abstract description 26
- 238000012545 processing Methods 0.000 claims abstract description 14
- 238000012216 screening Methods 0.000 claims abstract description 8
- 238000006243 chemical reaction Methods 0.000 claims description 17
- 230000008569 process Effects 0.000 claims description 11
- 238000007405 data analysis Methods 0.000 claims description 2
- 238000004519 manufacturing process Methods 0.000 abstract description 11
- 230000002411 adverse Effects 0.000 abstract description 4
- 230000000694 effects Effects 0.000 abstract description 3
- 238000012360 testing method Methods 0.000 description 7
- 238000010586 diagram Methods 0.000 description 5
- 238000013507 mapping Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 230000002085 persistent effect Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- OKTJSMMVPCPJKN-UHFFFAOYSA-N Carbon Chemical compound [C] OKTJSMMVPCPJKN-UHFFFAOYSA-N 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000007667 floating Methods 0.000 description 1
- 229910021389 graphene Inorganic materials 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/20—Natural language analysis
- G06F40/205—Parsing
- G06F40/226—Validation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/242—Query formulation
- G06F16/2433—Query languages
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
- G06F16/83—Querying
- G06F16/832—Query formulation
Abstract
The application relates to the technical field of big data processing, and provides a parameter verification method, a parameter verification device, computer equipment, a storage medium and a computer program product. The method comprises the following steps: acquiring an XML file of Mybatis to be analyzed, analyzing the XML file, acquiring condition parameters and target objects corresponding to each SQL node identification data in the XML file, checking each condition parameter based on the corresponding relation between the preset condition parameters and the target objects, screening out abnormal condition parameters, and recording the abnormal condition parameters and the SQL node identification data corresponding to the abnormal condition parameters to a preset data structure. By adopting the method, abnormal condition parameters which do not meet the specification requirements in Mybatis can be checked uniformly, and the possibility that logic errors or index failure cause adverse effects on the performance of the production environment due to the fact that the condition parameters are wrote in errors is reduced.
Description
Technical Field
The present invention relates to the field of big data processing technology, and in particular, to a parameter verification method, apparatus, computer device, storage medium, and computer program product.
Background
With the rapid development of computer technology, in large Java applications, it is a common approach to use a persistent layer framework to simplify database operations. The Mybatis framework is used as a persistent layer framework, and is increasingly widely used because of the advantages of supporting customized SQL (Structured Query Language, structured language), storage process, high-level correspondence and the like.
In general, when a developer writes an SQL statement in XML (EXtensible Markup Language ), in order to satisfy that the SQL node identification data of one Mybatis can be used by multiple business scenarios, multiple condition parameters are often configured, and because the condition parameters are written in a character string of a specific tag, if a writing error occurs, in an actual compiling process, a situation different from a preset logic occurs, and in severe cases, the influence of production environment performance is also caused.
It can be seen that there is a need to provide a solution for uniformly verifying the condition parameters in the SQL statement in the Mybatis framework.
Disclosure of Invention
In view of the foregoing, it is desirable to provide a parameter verification method, apparatus, computer device, computer readable storage medium, and computer program product that can uniformly verify condition parameters in SQL statements in Mybatis framework.
In a first aspect, the present application provides a parameter verification method. The method comprises the following steps:
acquiring an XML file of Mybatis to be analyzed;
analyzing the XML file to obtain condition parameters and target objects corresponding to the SQL node identification data in the XML file;
and checking each condition parameter based on the corresponding relation between the preset condition parameter and the target object, and screening out abnormal condition parameters.
In one embodiment, the preset correspondence between the condition parameter and the target object includes a correspondence between the condition parameter and an attribute of the target object;
based on the corresponding relation between the preset condition parameters and the target object, the verification of each condition parameter comprises the following steps:
performing field name verification on each condition parameter based on the corresponding relation between the condition parameter and the attribute of the target object;
and if the condition parameters pass the field name verification, performing data type verification and/or database field verification on the condition parameters.
In one embodiment, performing field name verification on each condition parameter based on a correspondence between the condition parameter and an attribute of the target object includes:
based on the corresponding relation between the condition parameters and the attributes of the target object, comparing whether the condition parameters exist in the attributes of the target object or not by adopting a character string full matching mode;
If the condition parameter exists in the attribute of the target object, judging that the condition parameter passes the field name verification.
In one embodiment, the preset correspondence between the condition parameter and the target object includes a correspondence between a data type of the condition parameter and a data type of the target object;
the data type checking of the condition parameters comprises the following steps:
identifying a first data type of the condition parameter and a second data type of a target object corresponding to the condition parameter;
if the first data type is judged to be matched with the second data type according to the corresponding relation between the data type of the condition parameter and the data type of the target object, the condition parameter is judged to pass the data type verification.
In one embodiment, database field checking of the condition parameters includes:
naming and converting the condition parameters to obtain database fields to be compared;
acquiring an original database field corresponding to the condition parameter;
and if the database field to be compared is consistent with the original database field, judging that the condition parameters pass through the database field verification.
In one embodiment, performing naming conversion processing on the condition parameters to obtain database fields to be compared includes:
And carrying out naming conversion treatment on the condition parameters according to hump naming rules to obtain database fields to be compared.
In one embodiment, after screening out the abnormal condition parameters, the method further comprises:
recording the abnormal condition parameters and SQL node identification data corresponding to the abnormal condition parameters to different preset data structures.
In one embodiment, recording the abnormal condition parameters and the SQL node identification data corresponding to the abnormal condition parameters to different preset data structures includes:
and recording the abnormal condition parameters and SQL node identification data corresponding to the abnormal condition parameters to different preset List data structures according to the check types corresponding to the abnormal condition parameters.
In one embodiment, after the abnormal condition parameters and the SQL node identification data corresponding to the abnormal condition parameters are recorded to the preset data structure, the method further includes:
pushing the abnormal condition parameters and SQL node identification data corresponding to the abnormal condition parameters.
In a second aspect, the present application further provides a parameter verification apparatus. The device comprises:
the data acquisition module is used for acquiring an XML file of Mybatis to be analyzed;
The data analysis module is used for analyzing the XML file and acquiring condition parameters and target objects corresponding to the SQL node identification data in the XML file;
and the parameter verification module is used for verifying each condition parameter based on the corresponding relation between the preset condition parameter and the target object and screening out abnormal condition parameters.
In one embodiment, the preset correspondence between the condition parameter and the target object includes a correspondence between the condition parameter and an attribute of the target object;
the parameter verification module is further configured to perform field name verification on each condition parameter based on a corresponding relationship between the condition parameter and the attribute of the target object, and if the condition parameter passes the field name verification, perform data type verification and/or database field verification on the condition parameter.
In one embodiment, the parameter verification module is further configured to compare whether the condition parameter exists in the attribute of the target object by adopting a character string full matching manner based on the correspondence between the condition parameter and the attribute of the target object, and if the condition parameter exists in the attribute of the target object, determine that the condition parameter passes the field name verification.
In one embodiment, the preset correspondence between the condition parameter and the target object includes a correspondence between a data type of the condition parameter and a data type of the target object;
The parameter verification module is further configured to identify a first data type of the condition parameter and a second data type of the target object corresponding to the condition parameter, and if the first data type and the second data type are determined to be matched according to the corresponding relationship between the data type of the condition parameter and the data type of the target object, determine that the condition parameter passes the data type verification.
In one embodiment, the parameter verification module is further configured to perform naming conversion processing on the condition parameters to obtain a database field to be compared, obtain an original database field corresponding to the condition parameters, and if the database field to be compared is consistent with the original database field, determine that the condition parameters pass through the database field verification.
In one embodiment, the parameter verification module is further configured to perform naming conversion processing on the condition parameters according to a hump naming rule, so as to obtain a database field to be compared.
In one embodiment, the device further includes a data recording module, configured to record the abnormal condition parameter and the SQL node identification data corresponding to the abnormal condition parameter to different preset data structures.
In one embodiment, the data recording module is further configured to record the abnormal condition parameter and the SQL node identifier data corresponding to the abnormal condition parameter to different preset List data structures according to the check type corresponding to the abnormal condition parameter.
In one embodiment, the device further includes a data pushing module, configured to push the abnormal condition parameter and SQL node identification data corresponding to the abnormal condition parameter.
In a third aspect, the present application also provides a computer device. The computer device comprises a memory storing a computer program and a processor implementing the steps of the parameter verification method described above when the processor executes the computer program.
In a fourth aspect, the present application also provides a computer-readable storage medium. The computer readable storage medium has stored thereon a computer program which, when executed by a processor, implements the steps of the parameter verification method described above.
In a fifth aspect, the present application also provides a computer program product. The computer program product comprises a computer program which, when executed by a processor, implements the steps of the above-mentioned parameter verification method.
The parameter verification method, the device, the computer equipment, the storage medium and the computer program product acquire the XML file of Mybatis to be analyzed, then analyze the XML file, acquire the condition parameters and the target objects corresponding to each SQL node identification data in the XML file, verify the condition parameters based on the corresponding relation between the preset condition parameters and the target objects, and screen out abnormal condition parameters. According to the process, the condition parameters under the Mybatis frame are checked based on the corresponding relation between each preset condition parameter and the target object, so that abnormal condition parameters which do not meet the standard requirements in the Mybatis can be checked uniformly, and the possibility that logic errors or index failure cause adverse effects on the production environment performance due to condition parameter writing errors is reduced. Furthermore, the scheme can be used as a conventional measure for checking potential safety hazards in the daily production version changing process in the Mybatis framework, and the stability of the production environment can be further ensured.
Drawings
FIG. 1 is a diagram of an application environment for a parameter verification method in one embodiment;
FIG. 2 is a flow chart of a parameter verification method in one embodiment;
FIG. 3 is a flow chart of a parameter verification method according to another embodiment;
FIG. 4 is a detailed flow chart of a parameter verification method in one embodiment;
FIG. 5 is a detailed flowchart of a parameter verification method according to another embodiment;
FIG. 6 is a detailed flowchart of a parameter verification method according to another embodiment;
FIG. 7 is a block diagram of a parameter verification apparatus in one embodiment;
FIG. 8 is a block diagram of a parameter verification apparatus in another embodiment;
fig. 9 is an internal structural diagram of a computer device in one embodiment.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be further described in detail with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present application.
It should be noted that, the user information (including, but not limited to, user equipment information, user personal information, etc.) and the data (including, but not limited to, data for analysis, stored data, presented data, etc.) referred to in the present application are information and data authorized by the user or sufficiently authorized by each party, and the collection, use and processing of the related data are required to comply with the related laws and regulations and standards of the related countries and regions.
The parameter verification method provided by the embodiment of the application can be applied to an application environment shown in fig. 1. Wherein the terminal 102 communicates with the server 104 via a network. The data storage system may store data that the server 104 needs to process. The data storage system may be integrated on the server 104 or may be located on a cloud or other network server. Specifically, a developer uploads an XML file of Mybatis to be parsed to the server 104 through the terminal 102, then sends a parameter verification message to the server 104 through the terminal 102, the server 104 responds to the message to obtain the XML file of Mybatis to be parsed, then parses the XML file to obtain condition parameters and target objects corresponding to each SQL node identification data in the XML file, and then verifies each condition parameter based on the corresponding relation between the preset condition parameters and the target objects to screen out abnormal condition parameters. The terminal 102 may be, but not limited to, various personal computers, notebook computers, smart phones, tablet computers, internet of things devices, and portable wearable devices, where the internet of things devices may be smart speakers, smart televisions, smart air conditioners, smart vehicle devices, and the like. The portable wearable device may be a smart watch, smart bracelet, headset, or the like. The server 104 may be implemented as a stand-alone server or as a server cluster of multiple servers.
In one embodiment, as shown in fig. 2, a parameter verification method is provided, and the method is applied to the server 104 in fig. 1 for illustration, and includes the following steps:
step S100, an XML file of Mybatis to be analyzed is obtained.
Mybatis is a persistent layer framework supporting custom SQL, stored procedures, and high-level mappings that can configure and map native mappings using simple XML or annotations for simplifying operations on databases. The XML file of Mybatis to be parsed is a file containing SQL statements. In this embodiment, the XML file to be parsed may be a batch of XML files. In practical application, when a developer writes an SQL statement in XML, in order to meet the requirement that SQL node identification data of one Mybatis can be used by a plurality of business scenes, a plurality of condition parameters are often configured during writing. Because Mybatis's SQL or condition judgement is written in XML or specific character string, when parameter spelling is wrong, the compiler can not fully detect, so that the condition that actual logic is different from preset logic easily occurs, and fault is caused. Based on the method, parameters with writing errors can be detected by uniformly checking the XML file of Mybatis.
In the implementation, a developer can upload XML files of Mybatis to be checked to a server in batches through a terminal, specifically, upload catalogues of batch XML files to be scanned and XML files to the server, and send parameter checking information to the server through the terminal. And the server responds to the parameter verification message, acquires the XML file of the uploaded Mybatis, and determines the XML file as the XML file to be analyzed.
And step 200, analyzing the XML file to obtain the condition parameters and the target objects corresponding to the SQL node identification data in the XML file.
In this embodiment, the target object is a Java object. The SQL node identification data includes an ID (identity), name or number, etc. of the SQL node. In this embodiment, the SQL node identification data is exemplified by an ID of an SQL node (hereinafter referred to as SQL-ID). The SQL-ID is a label used for identifying a dynamic SQL in Mybatis, and Mybatis is spliced into an executable SQL statement by calling the SQL-ID and transmitting corresponding parameters.
In the previous embodiment, after the XML file to be parsed is obtained, the XML file may be scanned and parsed sequentially to obtain the condition parameters and the target objects corresponding to the identification data of each SQL node in the XML file. Specifically, the tool for analyzing the XML by Java may sequentially obtain SQL_IDs in XML files in Mybatis, and then obtain the full path of Java objects of parameter classes in each SQL_ID in a single XML file and SQL condition parameters (hereinafter referred to as condition parameters) in SQL_IDs.
Examples of Mybatis band condition parameters are as follows:
select test_a,test_b,test_c from test where 1＝1
<if test＝’testA！＝null’>and test_a＝#{testA}</if>
<if test＝’testB！＝null’>and test_b＝#{testB}</if>
<if test＝’testC！＝null’>and test_c＝#{testC}</if>
the condition parameter testA in the if tag is a Java object, and test_a is a database field.
Step S300, based on the corresponding relation between the preset condition parameters and the target object, checking each condition parameter, and screening out abnormal condition parameters.
Mybatis is an object relational mapping framework used to decouple SQL statements from Java code. The XML file contains the writing of SQL sentences and the mapping rules of Java objects.
In this embodiment, after the condition parameters and the Java object are acquired, the condition parameters may be checked based on a preset correspondence between the condition parameters and the target object. Specifically, one SQL node identification data may include a plurality of condition parameters, which may be based on the corresponding relationship between the condition parameters and Java objects by using the SQL node identification data as a unit, and sequentially check the plurality of condition parameters under the SQL node identification data to detect whether the condition parameters in the SQL node identification data have writing errors, and sift out abnormal condition parameters with writing errors. Specifically, the verification may include verification of multiple aspects, such as verification of field names, verification of field types, consistency verification, validity verification, verification of other aspects, and the like, which are not limited herein, and may be specifically determined according to actual verification requirements.
In the above parameter verification method, an XML file of Mybatis to be parsed is obtained, then the XML file is parsed, the condition parameters and the target objects corresponding to each SQL node identification data in the XML file are obtained, the condition parameters are verified based on the corresponding relation between the preset condition parameters and the target objects, and finally, the abnormal condition parameters and the SQL node identification data corresponding to the abnormal condition parameters are recorded in the preset data structure. According to the method, the condition parameters under the Mybatis frame are checked based on the corresponding relation between the preset condition parameters and the target object, so that abnormal condition parameters which do not meet the standard requirements in the Mybatis frame can be checked uniformly, the possibility that the performance of the production environment is adversely affected by logic errors or index failure due to error writing of the condition parameters is further reduced, and the method can be used as a conventional measure for checking potential safety hazards in the daily production version changing process in the Mybatis frame, and the stability of the production environment can be further ensured.
As shown in fig. 3, after step S300, the method further includes: step S400, recording the abnormal condition parameters and SQL node identification data corresponding to the abnormal condition parameters to a preset data structure.
The preset data structure may be a set data structure or a List data structure. In the implementation, the condition parameters can be checked in sequence according to the corresponding relation between the condition parameters and the Java object, if the condition parameters pass the check, the next condition parameters are checked continuously, and if the condition parameters do not pass the check, the abnormal condition parameters and SQL node identification data corresponding to the abnormal condition parameters can be recorded into a preset data structure, so that a developer can conveniently and timely locate and check the abnormal condition parameters with writing errors. In another embodiment, the abnormal condition parameters, the SQL node identification data corresponding to the abnormal condition parameters, and the line numbers where the condition parameters are located may be recorded into a preset data structure. In this embodiment, by recording the abnormal condition parameters into a preset data structure, it is convenient for a developer to check and check the problem in time.
In one embodiment, the preset correspondence between the condition parameter and the target object includes a correspondence between the condition parameter and an attribute of the target object;
as shown in fig. 3, step S300 includes:
step S320, performing field name verification on each condition parameter based on the corresponding relation between the condition parameter and the attribute of the target object.
Step S340, if the condition parameters pass the field name verification, the data type verification and the database field verification are performed on the condition parameters.
In practical application, the corresponding relation between the condition parameters and the Java object comprises the corresponding relation between the field names of the condition parameters and the attributes of the Java object, the corresponding relation between the field types and the like. Specifically, the condition parameters must exist in the java object, and the fields in the java object are not necessarily in the condition parameters. In this embodiment, the verification of the condition parameters may be that, based on the correspondence between the field names of the condition parameters and the attributes of the Java objects, the field names of the condition parameters are verified, whether there is an error in the field names of the condition parameters is written, if there is no error, the condition parameters are determined to pass the field name verification, and then, the data type verification or the database field verification is performed on the condition parameters passing the field name verification. In another embodiment, it may also be to perform a data type check and a database field check on the condition parameters that pass the field name check. In this embodiment, the multi-dimensional verification of the condition parameters can be implemented by performing field name verification on the condition parameters and further performing data type checksum or database field verification on the condition parameters passing the field name verification, so that the correctness of the condition parameters is further ensured.
As shown in fig. 4, in one embodiment, step S320 includes:
step S322, based on the corresponding relation between the condition parameters and the attributes of the target object, a character string full matching mode is adopted to judge whether the condition parameters pass the field name verification.
In this embodiment, the field name verification of the condition parameter may be based on the correspondence between the condition parameter and the attribute of the target object, and a character string full matching manner is adopted to compare whether the condition parameter exists in the attribute of the target object, if the condition parameter exists in the attribute of the target object, the condition parameter is determined to pass the field name verification, otherwise, the condition parameter is determined to not pass the field name verification. In the specific implementation, the attribute of the Java object corresponding to the condition parameter can be obtained through a Java reflection mode, then whether the condition parameter exists in the attribute of the Java object is compared according to a character string full matching mode, if a field which is completely consistent with the current condition parameter is found in the attribute of the Java object, the condition parameter is characterized by not having writing errors, the condition parameter is judged to pass field name verification, if the field which is completely consistent with the current condition parameter is not found, the condition parameter is characterized by having writing errors, and the condition parameter is judged to not pass field name verification. Furthermore, the condition parameters which do not pass the field name verification, the SQL node identification data corresponding to the condition parameters and the line number where the condition parameters are located can be recorded into a preset data structure. In this embodiment, by adopting a manner of full matching of character strings, whether the condition parameters pass the field name verification can be rapidly and accurately determined.
In one embodiment, the preset correspondence between the condition parameter and the target object includes a correspondence between a data type of the condition parameter and a data type of the target object;
as shown in fig. 4, step S340 includes: step S342, a first data type of the condition parameter and a second data type of the target object corresponding to the condition parameter are identified, and whether the first data type and the second data type are matched is judged according to the corresponding relation between the data type of the condition parameter and the data type of the target object so as to screen out the abnormal condition parameter.
The preset corresponding relation between the condition parameters and the target object comprises the corresponding relation between the data type of the condition parameters and the data type of the target object. The data types include integer types, floating point types, string types, time types, and the like. However, since in Mybatis and Java, the canonical definition for data types is different. Typically, a database data type, specifically jdbcType, is used in Mybatis, and Java type is used in the Java framework. Therefore, in order to realize unified verification of the data types, the corresponding relation between the data types of the condition parameters and the data types of the Java objects, such as the corresponding relation between jdbcType and Java type, can be preconfigured. For example, for INTEGER types, the specification for jdbcType for Mybatis defines "inter", while in Java framework the definition is "int". See specifically the correspondence between jdbcType and javaType in the industry.
In specific implementation, the method comprises the steps of identifying a first data type of a condition parameter, identifying a second data type of a Java object corresponding to the condition parameter, judging whether a one-to-one correspondence exists between the first data type and the second data type according to the correspondence between the data type of the condition parameter and the data type of a target object, judging that the condition parameter passes the data type verification if the one-to-one correspondence exists between the first data type and the second data type, and judging that the condition parameter does not pass the data type verification if the one-to-one correspondence exists between the first data type and the second data type. In this embodiment, the data type verification of the condition parameter can be quickly implemented through the corresponding relationship between the data type of the condition parameter and the data type of the target object.
As shown in fig. 4, in one embodiment, step S340 includes: in step S344, the naming conversion process is performed on the condition parameters to obtain the database fields to be compared, the original database fields corresponding to the condition parameters are obtained, and the abnormal condition parameters are screened out according to whether the database fields to be compared are consistent with the original database fields.
In practical application, after the condition parameters pass the field name verification, database field verification can be performed on the condition parameters. Because of the naming differences between Java objects and database fields, it is necessary to convert the naming of the condition parameters before checking the database fields. In specific implementation, the condition parameters are named and converted according to a preset database field naming rule to obtain the database field to be compared, then the original database field corresponding to the condition parameters is obtained, whether the database field to be compared is consistent with the original database field or not is compared, and if the database field to be compared is consistent with the original database field, the condition parameters are judged to pass through the database field verification. In this embodiment, verification of the database field is implemented through naming conversion processing, so that condition parameters of writing errors of the database field can be effectively detected.
In one embodiment, performing naming conversion processing on the condition parameters to obtain database fields to be compared includes: and carrying out naming conversion treatment on the condition parameters according to hump naming rules to obtain database fields to be compared.
In practical applications, the fields in the condition parameters are typically Java objects. In this embodiment, naming conversion processing may be performed on the condition parameters according to a hump naming rule, so as to convert the target field into the database field to be compared which accords with the naming specification of the database field. Specifically, the upper case letter in the target field is converted into the lower case letter according to the hump naming rule, and the left position of the lower case letter is underlined to obtain the database field to be compared. For example, take the example of Mybatis band condition parameters as follows: select test_a, test_b, test_ c from test where 1=1
<if test＝’testA！＝null’>and test_a＝#{testA}</if>
The method comprises the steps that a target field testA in condition parameters in an if tag is a java object, and test_a is an original database field corresponding to the testA. The test A can be converted into test_a according to a hump naming rule, and the test_a to be compared obtained after conversion is compared with the original test_a, so that the condition parameter can be judged to pass through the database field parameter verification. In this embodiment, the field of the condition parameter is named and converted by the hump naming rule, so that the field of the condition parameter can be accurately converted into the database field, and the speed of checking the subsequent database field is improved.
As shown in fig. 4, in one embodiment, step S400 includes: step S420, according to the check type corresponding to the abnormal condition parameter, recording the abnormal condition parameter and SQL node identification data corresponding to the abnormal condition parameter to different preset List data structures.
The preset data structure may be a List data structure or a set data structure, and in this embodiment, the List data structure is taken as an example of the data structure. The exception condition parameters and the corresponding SQL_IDs may be correspondingly recorded into different data structures for different check types. For example, for field name verification, a condition parameter that fails the field name verification and the sql_id corresponding to the condition parameter may be recorded into the List1 data structure; aiming at data type verification, recording the condition parameters which do not pass the data type verification and SQL_ID corresponding to the condition parameters into a List2 data structure; aiming at the database field verification, the condition parameters which are not verified by the database field and SQL_ID corresponding to the condition parameters are recorded into a List3 data structure. In this embodiment, according to different verification types, the failed condition parameters and the corresponding sql_ids are recorded in the corresponding data structures respectively, so that developers can more purposefully correct the abnormal condition parameters, and the List data structures can also store line numbers, so that the abnormal condition parameters can be positioned quickly. In another embodiment, in addition to recording the condition parameters and the sql_ids corresponding to the condition parameters, the line numbers where the condition parameters are located may be recorded in the List data structure, so that a developer can quickly locate the condition parameters where writing errors exist.
As shown in fig. 5, in one embodiment, after step S400, the method further includes: step S500, pushing the SQL node identification data corresponding to the abnormal condition parameters.
In the practical application, after recording the abnormal condition parameters and the SQL node identification data corresponding to the abnormal condition parameters to the preset data structure, the abnormal condition parameters and the SQL node identification data corresponding to the abnormal condition parameters recorded in the data structure can be pushed. Specifically, the abnormal condition parameters and the SQL node identification data corresponding to the abnormal condition parameters may be output to the console, so that the developer can intuitively know the abnormal condition parameters. In another embodiment, the abnormal condition parameters, the SQL node identification data corresponding to the abnormal condition parameters and the line number of the SQL node identification data are output to the console, so that a developer can quickly locate the abnormal condition parameters.
For a clearer description of the parameter verification method provided in the present application, the following description may be made with reference to fig. 6 and a specific embodiment, which includes the following steps:
step S100, an XML file of Mybatis to be analyzed is obtained.
And step 200, analyzing the XML file to obtain the condition parameters and the target objects corresponding to the SQL node identification data in the XML file.
Specifically, the tool for analyzing the XML by Java may sequentially obtain SQL_IDs in XML files in Mybatis, and then obtain the full path of Java objects of parameter classes in each SQL_ID in a single XML file and SQL condition parameters (hereinafter referred to as condition parameters) in SQL_IDs.
Step S324, based on the corresponding relation between the condition parameters and the attributes of the target object, a character string full matching mode is adopted to judge whether the condition parameters pass the field name verification.
Specifically, a character string full matching mode may be adopted to compare whether the condition parameter exists in the attribute of the target object, if the condition parameter exists in the attribute of the target object, the condition parameter is determined to pass the field name verification, and step S342 is entered, otherwise, the condition parameter is determined not to pass the field name verification, and the next condition parameter is verified.
Step S342, a first data type of the condition parameter and a second data type of the target object corresponding to the condition parameter are identified, and whether the first data type and the second data type are matched is judged according to the corresponding relation between the data type of the condition parameter and the data type of the target object so as to screen out the abnormal condition parameter.
Specifically, if the first data type and the second data type are judged to be matched according to the corresponding relation between the data type of the condition parameter and the data type of the target object, the condition parameter is judged to pass the data type verification. Otherwise, the condition parameters are judged not to pass the data type verification.
In step S344, the naming conversion process is performed on the condition parameters to obtain the database fields to be compared, the original database fields corresponding to the condition parameters are obtained, and the abnormal condition parameters are screened out according to whether the database fields to be compared are consistent with the original database fields.
Specifically, if the database field to be compared is consistent with the original database field, judging that the condition parameters pass the database field verification, and if the condition parameters do not pass the database field verification, judging that the condition parameters do not pass the database field verification.
Step S422, according to the check type corresponding to the abnormal condition parameter, recording the abnormal condition parameter, SQL node identification data corresponding to the abnormal condition parameter and the line number to different List data structures.
For field name verification, a condition parameter which does not pass field name verification and SQL_ID corresponding to the condition parameter can be recorded into a List1 data structure; aiming at data type verification, recording the condition parameters which do not pass the data type verification and SQL_ID corresponding to the condition parameters into a List2 data structure; aiming at the database field verification, the condition parameters which are not verified by the database field and SQL_ID corresponding to the condition parameters are recorded into a List3 data structure.
Step S520, pushing the abnormal condition parameters, SQL node identification data corresponding to the abnormal condition parameters and the row number.
Specifically, the abnormal condition parameters and the SQL node identification data corresponding to the abnormal condition parameters may be output to the console, so that the developer can intuitively know the abnormal condition parameters.
It should be understood that, although the steps in the flowcharts related to the embodiments described above are sequentially shown as indicated by arrows, these steps are not necessarily sequentially performed in the order indicated by the arrows. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps in the flowcharts described in the above embodiments may include a plurality of steps or a plurality of stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of the steps or stages is not necessarily performed sequentially, but may be performed alternately or alternately with at least some of the other steps or stages.
Based on the same inventive concept, the embodiment of the application also provides a parameter verification device for realizing the parameter verification method. The implementation of the solution provided by the device is similar to the implementation described in the above method, so the specific limitation in the embodiments of the one or more parameter verification devices provided below may be referred to the limitation of the parameter verification method hereinabove, and will not be repeated herein.
In one embodiment, as shown in fig. 7, there is provided a parameter verification apparatus 700, comprising: a data acquisition module 710, a data parsing module 720, a parameter verification module 730, and a data recording module 740, wherein:
the data obtaining module 710 is configured to obtain an XML file of Mybatis to be parsed.
The data parsing module 720 is configured to parse the XML file, and obtain the condition parameters and the target objects corresponding to the identifier data of each SQL node in the XML file.
And a parameter verification module 730, configured to verify each condition parameter based on a corresponding relationship between the preset condition parameter and the target object.
In the parameter verification device, an XML file of Mybatis to be analyzed is obtained, then the XML file is analyzed, the condition parameters and the target objects corresponding to the SQL node identification data in the XML file are obtained, the condition parameters are verified based on the corresponding relation between the preset condition parameters and the target objects, and finally the abnormal condition parameters and the SQL node identification data corresponding to the abnormal condition parameters are recorded in a preset data structure. According to the process, the condition parameters under the Mybatis frame are checked based on the corresponding relation between each preset condition parameter and the target object, so that abnormal condition parameters which do not meet the standard requirements in the Mybatis can be checked uniformly, and the possibility that logic errors or index failure cause adverse effects on the production environment performance due to condition parameter writing errors is reduced. Furthermore, the scheme can be used as a conventional measure for checking potential safety hazards in the daily production version changing process in the Mybatis framework, and the stability of the production environment can be further ensured.
In one embodiment, the preset correspondence between the condition parameter and the target object includes a correspondence between the condition parameter and an attribute of the target object;
the parameter verification module 730 is further configured to perform field name verification on each condition parameter based on a corresponding relationship between the condition parameter and the attribute of the target object, and if the condition parameter passes the field name verification, perform data type verification and/or database field verification on the condition parameter.
In one embodiment, the parameter verification module 730 is further configured to compare whether the condition parameter exists in the attribute of the target object in a manner of fully matching the character string based on the correspondence between the condition parameter and the attribute of the target object, and if the condition parameter exists in the attribute of the target object, determine that the condition parameter passes the field name verification.
In one embodiment, the preset correspondence between the condition parameter and the target object includes a correspondence between a data type of the condition parameter and a data type of the target object;
the parameter verification module 730 is further configured to identify a first data type of the condition parameter and a second data type of the target object corresponding to the condition parameter, and if the first data type and the second data type are determined to match according to the corresponding relationship between the data type of the condition parameter and the data type of the target object, determine that the condition parameter passes the data type verification.
In one embodiment, the parameter verification module 730 is further configured to perform naming conversion processing on the condition parameters to obtain a database field to be compared, obtain an original database field corresponding to the condition parameters, and if the database field to be compared is consistent with the original database field, determine that the condition parameters pass through the database field verification.
In one embodiment, the parameter verification module 730 is further configured to perform naming conversion processing on the condition parameters according to the hump naming rule, so as to obtain the database field to be compared.
As shown in fig. 8, the apparatus further includes a data recording module 740 configured to record the abnormal condition parameters and the SQL node identification data corresponding to the abnormal condition parameters to a preset data structure.
In one embodiment, the data recording module 740 is further configured to record the abnormal condition parameters and the SQL node identification data corresponding to the abnormal condition parameters to different preset List data structures according to the check types corresponding to the abnormal condition parameters.
As shown in fig. 8, in one embodiment, the apparatus further includes a data pushing module 750, configured to push the abnormal condition parameter and the SQL node identification data corresponding to the abnormal condition parameter.
The above-mentioned respective modules in the parameter verification apparatus may be implemented in whole or in part by software, hardware, and combinations thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.
In one embodiment, a computer device is provided, which may be a server, and the internal structure of which may be as shown in fig. 9. The computer device includes a processor, a memory, an Input/Output interface (I/O) and a communication interface. The processor, the memory and the input/output interface are connected through a system bus, and the communication interface is connected to the system bus through the input/output interface. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database of the computer equipment is used for storing the XML file to be analyzed, abnormal condition parameters and other data. The input/output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a parameter verification method.
It will be appreciated by those skilled in the art that the structure shown in fig. 9 is merely a block diagram of a portion of the structure associated with the present application and is not limiting of the computer device to which the present application applies, and that a particular computer device may include more or fewer components than shown, or may combine some of the components, or have a different arrangement of components.
In one embodiment, a computer device is provided, comprising a memory and a processor, the memory having stored therein a computer program, the processor implementing the steps in the above-described parameter checking method when executing the computer program.
In one embodiment, a computer readable storage medium is provided having a computer program stored thereon, which when executed by a processor implements the steps of the above-described parameter verification method.
In an embodiment, a computer program product is provided comprising a computer program which, when executed by a processor, implements the steps of the above-described parameter verification method.
Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, database, or other medium used in the various embodiments provided herein may include at least one of non-volatile and volatile memory. The nonvolatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical Memory, high density embedded nonvolatile Memory, resistive random access Memory (ReRAM), magnetic random access Memory (Magnetoresistive Random Access Memory, MRAM), ferroelectric Memory (Ferroelectric Random Access Memory, FRAM), phase change Memory (Phase Change Memory, PCM), graphene Memory, and the like. Volatile memory can include random access memory (Random Access Memory, RAM) or external cache memory, and the like. By way of illustration, and not limitation, RAM can be in the form of a variety of forms, such as static random access memory (Static Random Access Memory, SRAM) or dynamic random access memory (Dynamic Random Access Memory, DRAM), and the like. The databases referred to in the various embodiments provided herein may include at least one of relational databases and non-relational databases. The non-relational database may include, but is not limited to, a blockchain-based distributed database, and the like. The processors referred to in the embodiments provided herein may be general purpose processors, central processing units, graphics processors, digital signal processors, programmable logic units, quantum computing-based data processing logic units, etc., without being limited thereto.
The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.
The above examples only represent a few embodiments of the present application, which are described in more detail and are not to be construed as limiting the scope of the present application. It should be noted that it would be apparent to those skilled in the art that various modifications and improvements could be made without departing from the spirit of the present application, which would be within the scope of the present application. Accordingly, the scope of protection of the present application shall be subject to the appended claims.
Claims (21)
1. A method for parameter verification, the method comprising:
acquiring an XML file of Mybatis to be analyzed;
analyzing the XML file to obtain condition parameters and target objects corresponding to each SQL node identification data in the XML file;
and verifying the condition parameters based on the corresponding relation between the preset condition parameters and the target object, and screening out abnormal condition parameters.
2. The method according to claim 1, wherein the correspondence between the preset condition parameter and the target object includes a correspondence between the condition parameter and an attribute of the target object;
the verifying the condition parameter based on the preset corresponding relation between the preset condition parameter and the target object comprises:
performing field name verification on the condition parameters based on the corresponding relation between the condition parameters and the attributes of the target object;
and if the condition parameters pass the field name verification, performing data type verification and/or database field verification on the condition parameters.
3. The method according to claim 2, wherein the performing the field name check on the condition parameter based on the correspondence between the field name of the piece parameter and the attribute of the target object includes:
based on the corresponding relation between the condition parameters and the attributes of the target object, comparing whether the condition parameters exist in the attributes of the target object or not by adopting a character string full matching mode;
and if the condition parameters exist in the attribute of the target object, judging that the condition parameters pass the field name verification.
4. The method according to claim 2, wherein the correspondence between the preset condition parameter and the target object includes a correspondence between a data type of the condition parameter and a data type of the target object;
The data type checking of the condition parameters comprises the following steps:
identifying a first data type of the condition parameter and a second data type of a target object corresponding to the condition parameter;
and if the first data type is judged to be matched with the second data type according to the corresponding relation between the data type of the condition parameter and the data type of the target object, judging that the condition parameter passes the data type verification.
5. The method of claim 2, wherein performing a database field check on the condition parameter comprises:
naming conversion treatment is carried out on the condition parameters to obtain database fields to be compared;
acquiring an original database field corresponding to the condition parameter;
and if the database field to be compared is consistent with the original database field, judging that the condition parameters pass through the database field verification.
6. The method of claim 5, wherein naming the condition parameters to be converted to database fields to be compared comprises:
and carrying out naming conversion treatment on the condition parameters according to hump naming rules to obtain database fields to be compared.
7. The method according to any one of claims 1 to 6, wherein after screening out abnormal condition parameters, the method further comprises:
and recording the SQL node identification data corresponding to the abnormal condition parameters to different preset data structures.
8. The method of claim 7, wherein the recording the abnormal-condition parameters and the SQL node identification data corresponding to the abnormal-condition parameters to different preset data structures comprises:
and recording the abnormal condition parameters and SQL node identification data corresponding to the abnormal condition parameters to different preset List data structures according to the check types corresponding to the abnormal condition parameters.
9. The method according to any one of claims 1 to 6, wherein after the recording, in a preset data structure, the abnormal condition parameter and the SQL node identification data corresponding to the abnormal condition parameter, the method further comprises:
pushing the abnormal condition parameters and SQL node identification data corresponding to the abnormal condition parameters.
10. A parameter verification apparatus, said apparatus comprising:
The data acquisition module is used for acquiring an XML file of Mybatis to be analyzed;
the data analysis module is used for analyzing the XML file and acquiring condition parameters and target objects corresponding to the SQL node identification data in the XML file;
and the parameter verification module is used for verifying the condition parameters based on the preset corresponding relation between the preset condition parameters and the target object and screening out abnormal condition parameters.
11. The apparatus according to claim 10, wherein the correspondence between the preset condition parameter and the target object includes a correspondence between the condition parameter and an attribute of the target object;
the parameter verification module is further configured to perform field name verification on the condition parameter based on a corresponding relationship between the condition parameter and the attribute of the target object, and if the condition parameter passes the field name verification, perform data type verification and/or database field verification on the condition parameter.
12. The apparatus of claim 11, wherein the parameter verification module is further configured to compare whether the condition parameter exists in the attribute of the target object in a manner of fully matching the character string based on the correspondence between the condition parameter and the attribute of the target object, and determine that the condition parameter passes the field name verification if the condition parameter exists in the attribute of the target object.
13. The apparatus according to claim 11, wherein the correspondence between the preset condition parameter and the target object includes a correspondence between a data type of the condition parameter and a data type of the target object;
the parameter verification module is further configured to identify a first data type of the condition parameter and a second data type of a target object corresponding to the condition parameter, and determine that the condition parameter passes the data type verification if the first data type is determined to be matched with the second data type according to a correspondence between the data type of the condition parameter and the data type of the target object.
14. The apparatus of claim 11, wherein the parameter verification module is further configured to perform a naming conversion process on the condition parameter to obtain a database field to be compared, obtain an original database field corresponding to the condition parameter, and determine that the condition parameter passes a database field verification if the database field to be compared is identical to the original database field.
15. The apparatus of claim 14, wherein the parameter verification module is further configured to perform naming conversion processing on the condition parameters according to a hump naming rule, to obtain database fields to be compared.
16. The apparatus according to any one of claims 10 to 15, further comprising a data recording module configured to record the abnormal-condition parameter and the SQL node identification data corresponding to the abnormal-condition parameter to different preset data structures.
17. The apparatus of claim 16, wherein the data recording module is further configured to record the abnormal condition parameters and the SQL node identification data corresponding to the abnormal condition parameters to different preset List data structures according to a check type corresponding to the abnormal condition parameters.
18. The apparatus according to any one of claims 10 to 15, further comprising a data pushing module, configured to push the abnormal-condition parameter and SQL node identification data corresponding to the abnormal-condition parameter.
19. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor implements the steps of the method of any one of claims 1 to 9 when the computer program is executed.
20. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any of claims 1 to 9.
21. A computer program product comprising a computer program, characterized in that the computer program, when being executed by a processor, implements the steps of the method of any one of claims 1 to 9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310317267.2A CN116362230A (en) | 2023-03-27 | 2023-03-27 | Parameter verification method, device and computer equipment storable medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310317267.2A CN116362230A (en) | 2023-03-27 | 2023-03-27 | Parameter verification method, device and computer equipment storable medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116362230A true CN116362230A (en) | 2023-06-30 |
Family
ID=86917291
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310317267.2A Pending CN116362230A (en) | 2023-03-27 | 2023-03-27 | Parameter verification method, device and computer equipment storable medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116362230A (en) |
-
2023
- 2023-03-27 CN CN202310317267.2A patent/CN116362230A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10540270B1 (en) | Representation-based automated software testing | |
| US10769228B2 (en) | Systems and methods for web analytics testing and web development | |
| AU2010319344B2 (en) | Managing record format information | |
| AU2015315203B2 (en) | Conditional validation rules | |
| CN107665171B (en) | Automatic regression testing method and device | |
| CN109800258B (en) | Data file deployment method, device, computer equipment and storage medium | |
| US20200210401A1 (en) | Proactive automated data validation | |
| CN110019116B (en) | Data tracing method, device, data processing equipment and computer storage medium | |
| CN114116496A (en) | Automatic testing method, device, equipment and medium | |
| CN112783867A (en) | Database optimization method for meeting real-time big data service requirements and cloud server | |
| CN112241370B (en) | API interface class checking method, system and device | |
| CN111078529B (en) | Client writing module testing method and device and electronic equipment | |
| CN116362230A (en) | Parameter verification method, device and computer equipment storable medium | |
| CN113238940A (en) | Interface test result comparison method, device, equipment and storage medium | |
| CN117331789A (en) | Log generation method, device, computer equipment and storage medium | |
| CN115629958A (en) | Universal field level automatic checking method and device for different service interfaces | |
| CN117370160A (en) | Code auditing method, apparatus, computer device, storage medium and program product | |
| CN117555955A (en) | Data conversion method, data conversion device, computer device, and storage medium | |
| CN116107889A (en) | Regression testing method and device for application program, computer equipment and storage medium | |
| CN115827478A (en) | Code viewing method and device, computer equipment and storage medium | |
| CN114090428A (en) | Information processing method, information processing device, computer-readable storage medium and computer equipment | |
| CN116737541A (en) | Test positioning method, device, computer equipment and computer storage medium | |
| CN117539856A (en) | Method and device for detecting number bin table, data management system, device and storage medium | |
| CN113419738A (en) | Interface document generation method and device and interface management equipment | |
| CN117171003A (en) | Method, device, equipment and computer readable storage medium for managing test cases |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |