A dynamic query condition transformation system and method based on syntax parsing

Abstract

The application relates to the technical field of enterprise-level application database query middleware, and discloses a dynamic query condition conversion system and method based on syntax analysis, which comprises the following modules: an initialization module, which is used for initializing a preset component; a lexical analysis module, which is used for generating a token sequence containing type and position information; a sequence verification module, which is used for obtaining a token sequence after verification; a syntax analysis module, which is used for performing syntax analysis on the token sequence after verification to generate a standardized AST; a local specification module, which is used for generating a local query specification of each AST node; an execution object generation module, which is used for generating an executable JPA Specification object; a type formatting module, which is used for type conversion on a query result; and a dynamic query and conversion module, which is used for receiving a new operator rule through a REST API to complete dynamic query condition conversion based on syntax analysis.

Description

Technical Field

[0001] This invention relates to the field of enterprise application database query middleware technology, specifically to a dynamic query condition transformation system and method based on syntax parsing. Background Technology

[0002] As enterprises deepen their digital transformation, the demand for dynamic queries in data-intensive applications is becoming increasingly urgent. Current dynamic query solutions based on Spring Data JPA have several core architectural problems:

[0003] The existing solution suffers from blurred module responsibilities, embedding query condition construction logic into business modules (such as the Service layer), resulting in deep coupling between business logic and data access logic. For example, the logic for querying "VIP customers with spending greater than 10,000" needs to be written directly in the customer management module. When the query conditions change, the source code of this business module needs to be modified, leading to high maintenance costs.

[0004] The syntax rules are closed, and supported query operators (such as equal to, greater than, and fuzzy matching) must be implemented through hard coding. Adding new operators (such as "included in a list") requires modifying the core conversion logic. Taking the jpa-spec library as an example, if support for the "in" operator is required, a dedicated in() method must be added and the expression processing logic must be modified, resulting in poor extensibility.

[0005] Entity adaptation is cumbersome, requiring repeated development of conversion logic for queries on different business entities (such as Customer, Order, and Product). For example, customer queries require writing CustomerSpecification, and order queries require writing OrderSpecification, resulting in a large amount of repetitive code and low development efficiency.

[0006] The scalability bottleneck is obvious; the complexity of query conditions is limited by the logic predefined during the development phase, and it cannot support user-defined complex combinations of conditions (such as multi-nested logic (A and B) or (C and (D or E))). To support this, the expression parsing logic needs to be refactored, which carries a high risk.

[0007] Troubleshooting is difficult because the query logic is scattered across various business modules. When abnormal query results occur, it is necessary to check the Specification construction logic in the business code one by one, which results in a long troubleshooting cycle (the average troubleshooting time is about 2 hours per instance).

[0008] Therefore, there is an urgent need for a dynamic query condition transformation solution that can decouple business modules from query logic, support complex custom conditions, and has good scalability. Summary of the Invention

[0009] To address the above technical problems, this invention proposes a dynamic query condition transformation system and method based on syntax parsing. The system specifically includes:

[0010] The initialization module is used to load the support layer configuration and initialize preset components during the Spring container startup phase.

[0011] The lexical analysis module is used to receive the raw query string uploaded by the user and perform lexical analysis to generate a token sequence containing type and location information;

[0012] The sequence verification module is used to traverse the token sequence and verify it to obtain the verified token sequence.

[0013] The syntax parsing module is used to perform syntax analysis on the verified token sequence and generate a standardized AST;

[0014] The local specification module is used to generate local query specifications for each AST node based on the standardized AST.

[0015] The execution object generation module is used to generate executable JPASpecification objects based on the local query specifications of each AST node;

[0016] The type formatting module is used to call the JPA Specification object to perform database queries and perform type conversion on the query results;

[0017] The dynamic query and transformation module is used to receive new operator rules through the REST API based on the query results after type conversion, and complete the dynamic query condition transformation based on syntax parsing.

[0018] Optionally, in the initialization module, the support layer configuration includes operator mapping rules and log monitoring parameters;

[0019] The preset components include a lexical analysis state machine, a DFA validator, a loading operator whitelist, a JSqlParser syntax parsing engine, and a registration processor.

[0020] Optionally, the workflow of the sequence verification module specifically includes:

[0021] Based on the stack data structure, the token sequence is traversed, and the matching of brackets is verified by checking LPAREN and RPAREN;

[0022] Based on the token sequence, lexical analysis is used to generate an OPERATOR type token. The string value of the OPERATOR type token is extracted, and the string value is compared and matched with a preset operator hash table to verify the operator validity of the token sequence.

[0023] Perform validity checks on the value format and enumeration values ​​in the token sequence.

[0024] Optionally, the process of verifying bracket matching by checking LPAREN and RPAREN is as follows:

[0025] If an LPAREN is encountered, push it onto the stack and record its position. If an RPAREN is encountered, check if the stack is empty. If the stack is empty, display an exception; otherwise, pop the top element from the stack. After traversal, check if the stack is empty. If the stack is not empty, throw an exception signal.

[0026] This invention also discloses a dynamic query condition transformation method based on syntax parsing, the method comprising:

[0027] During the Spring container startup phase, the support layer configuration is loaded and preset components are initialized.

[0028] Receive the raw query string uploaded by the user and perform lexical analysis to generate a token sequence containing type and location information;

[0029] Traverse the token sequence and verify it to obtain the verified token sequence;

[0030] The verified token sequence is subjected to syntactic analysis to generate a standardized AST;

[0031] Based on the standardized AST, local query specifications for each AST node are generated;

[0032] An executable JPA Specification object is generated based on the local query specifications of each AST node;

[0033] The JPA Specification object is invoked to perform a database query, and the query results are then type-converted.

[0034] Based on the query results after type conversion, new operator rules are received via REST API to complete dynamic query condition conversion based on syntax parsing.

[0035] Optionally, the support layer configuration includes operator mapping rules and log monitoring parameters;

[0036] The preset components include a lexical analysis state machine, a DFA validator, a loading operator whitelist, a JSqlParser syntax parsing engine, and a registration processor.

[0037] Optionally, the process of traversing the token sequence and performing verification specifically includes:

[0038] Based on the stack data structure, the token sequence is traversed, and the matching of brackets is verified by checking LPAREN and RPAREN;

[0039] Based on the token sequence, lexical analysis is used to generate an OPERATOR type token. The string value of the OPERATOR type token is extracted, and the string value is compared and matched with a preset operator hash table to verify the operator validity of the token sequence.

[0040] Perform validity checks on the value format and enumeration values ​​in the token sequence.

[0041] Optionally, the process of verifying bracket matching by checking LPAREN and RPAREN is as follows:

[0042] If an LPAREN is encountered, push it onto the stack and record its position. If an RPAREN is encountered, check if the stack is empty. If the stack is empty, display an exception; otherwise, pop the top element from the stack. After traversal, check if the stack is empty. If the stack is not empty, throw an exception signal.

[0043] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0044] This invention achieves complete decoupling between business modules and query logic by separating query logic from business modules, reducing the amount of data access code in business modules by 30% to 50%. Business developers do not need to learn the JPACriteria API, and the development cycle for integrating query functionality into new business entities is shortened from 2 days to 2 hours, significantly improving development efficiency. When adding new operators, only the mapping relationship needs to be added in the rule configuration center, reducing development workload by 80% and significantly enhancing scalability. It supports users to dynamically configure multiple nested query conditions (up to 8 levels) to meet the needs of complex business scenarios. The query logic is centralized in the engine module, and fault diagnosis can be traced through the log monitoring module to track the complete processing chain, reducing the average troubleshooting time from 4 hours to 30 minutes and lowering maintenance costs. Attached Figure Description

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

[0046] Figure 1 This is a system architecture diagram of a dynamic query condition transformation system based on syntax parsing provided in an embodiment of the present invention;

[0047] Figure 2 This is an example diagram of the AST node structure provided in an embodiment of the present invention. Detailed Implementation

[0048] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0049] Explanation of some terms in the embodiments:

[0050] Token: The smallest syntactic unit obtained after lexical analysis, containing type, value, and position information;

[0051] AST (Abstract Syntax Tree): Used to represent the syntactic structure of query conditions, reflecting the logical hierarchy of query conditions;

[0052] JPA Specification: The interface in Spring Data JPA used to build dynamic query conditions;

[0053] DFA (Deterministic Finite Automaton): A mathematical model used for validating the validity of operators;

[0054] Edit distance algorithm: used to calculate the similarity between two strings, and here used to recommend the closest legal operator.

[0055] Example 1:

[0056] A dynamic query condition transformation system based on syntax parsing, such as Figure 1 As shown, the system includes:

[0057] The initialization module is used during the Spring container startup phase to load the support layer configuration and initialize preset components. Methods for initializing the system context include:

[0058] During the Spring container startup phase (CommandLineRunner execution phase), operator mapping rules and log monitoring parameters are loaded; core components such as the lexical analysis state machine, DFA validator, and JSqlParser syntax parsing engine are initialized; and logic node processors, comparison node processors, and function node processors are registered.

[0059] The lexical analysis module receives the raw query string uploaded by the user, performs lexical analysis, and generates a token sequence containing type and location information. Lexical analysis methods include:

[0060] Initialize the state machine, setting the initial state to "DEFAULT"; traverse the original query string character by character, switch states according to preset rules and identify syntax units to generate corresponding tokens; record the start / end position of each token in the original query string.

[0061] The state transition rules include:

[0062] When encountering "(" or ")", an LPAREN or RPAREN Token is generated, and the state remains "DEFAULT". When encountering a single quote "'", the system enters the "STRING" state, reads the closing quote (supports escape characters "'"), generates a VALUE Token, and then switches back to the "DEFAULT" state. When encountering a letter or underscore, the system enters the "IDENTIFIER" state, reads consecutive characters, generates a FIELD or OPERATOR Token, and switches back to the "DEFAULT" state when encountering a non-alphanumeric / non-underscore character. When encountering a number or a minus sign "-", the system enters the "NUMBER" state, generates a VALUE Token (supports integers, decimals, and negative numbers), and switches back to the "DEFAULT" state when encountering a non-numeric / non-decimal point character.

[0063] The sequence verification module is used to traverse the token sequence and verify it to obtain the verified token sequence.

[0064] Methods for validating token sequences include:

[0065] Parentheses matching check: Based on the stack data structure, traverse the token sequence. When LPAREN is encountered, push it onto the stack and record its position. When RPAREN is encountered, check if the stack is empty. If the stack is empty, throw a "redundant closing parenthesis" exception. If it is not empty, pop the top element of the stack. If the stack is not empty after traversal, throw an "unclosed parenthesis" exception.

[0066] Validation objective: Ensure that the number of left parentheses (()) and right parentheses ()) in the query conditions is equal, and that the nesting relationship is valid (i.e., each left parenthesis has a corresponding right parenthesis to close it, and there are no cases of cross-nesting or unclosed parentheses).

[0067] Implementation method: Based on the stack data structure, the token sequence of the query conditions (such as LPAREN (left parenthesis) and RPAREN (right parenthesis) type tokens generated by lexical analysis) is traversed, and the stack push and pop logic is executed to verify the nested legality.

[0068] Specific procedures:

[0069] 1. Initialization: Create an empty stack to record the position information of the left parenthesis (to facilitate exception location).

[0070] 2. Traverse the Token sequence: 21. When encountering an LPAREN Token, push its position in the original string (e.g., starting index) onto the stack and mark it as "waiting for closure". 22. When encountering an RPAREN Token:

[0071] 221. If the stack is empty, it indicates the presence of an extra right parenthesis, and an exception is thrown (e.g., "Unmatched right parenthesis at position x"). 222. If the stack is not empty, pop the top element (the corresponding left parenthesis position) and mark it as "successfully closed". 223. End-of-traversal check:

[0072] 2231. If the stack is empty, it means that all left parentheses are closed, and the match is valid. 2232. If the stack is not empty, it means that there is an "unclosed left parenthesis", and an exception is thrown (such as "the left parenthesis at position y is not closed").

[0073] Example Explanation: Valid Case: (A and (B or C)) → During the traversal, left parentheses are pushed onto the stack in sequence, and right parentheses are popped off the stack in sequence, eventually resulting in an empty stack, and the check passes. Illegal Case: (A and (B or C) → After the traversal, there is still one unclosed left parenthesis in the stack, and the check fails; (A and B) or (C and D) → Similarly, the stack is not empty, and the check fails.

[0074] Verification of Operator Legality: Based on a deterministic finite automaton (DFA), pre-load the operator whitelist and construct the DFA state transition table. Traverse the Token of OPERATOR type, input the Token value into the DFA. If the accepting state is not reached, it is determined as an illegal operator, and the most similar legal operator is recommended using the edit distance algorithm; Verification Objective: Ensure that the operators used in the query conditions are all legal operators preset by the system (such as eq (equal), ne (not equal), gt (greater than), lt (less than), ge (greater than or equal to), le (less than or equal to), like (fuzzy matching), in (contained in), and (logical AND), or (logical OR), not (logical NOT), etc.), and the use of undefined operators (such as eqa, lik, etc.) is prohibited.

[0075] Implementation Method: Based on the preset operator set and the fast matching algorithm, combined with the exception prompt mechanism.

[0076] Specific Process: 1. Definition of Preset Operator Set: Load the preset operators through the configuration file or during the system initialization phase and store them in a hash table (HashSet) to achieve fast query with O(1) time complexity (such as validOperators = {"eq", "ne", "gt",..., "not"}). 2. Token-level Verification: After generating the Token of OPERATOR type in lexical analysis, extract the string value of the Token (such as "eqa") and check whether it exists in the preset operator set: If it exists, it is determined as a legal operator and proceeds to the next step. If it does not exist, it is determined as an illegal operator and an exception handling is triggered.

[0077] 3. Exception Handling and Optimization: Throw an exception, clearly prompt "Illegal Operator: xxx, supported operators include: eq, ne, gt...".

[0078] To improve the user experience, the similarity between the illegal operator and the preset operator can be calculated using the edit distance algorithm (such as the Levenshtein distance), and the most likely legal operator is recommended (for example, the edit distance between the illegal operator "eqa" and "eq" is 1, and "eq" is recommended). Example: Legal case: In custName eq '张三', eq is a preset operator and the verification passes. Illegal case: In orderAmount eqa 1000, eqa is not in the preset set, the verification fails, and the prompt "Illegal Operator eqa, it is recommended to use eq" is given.

[0079] Value format verification: Based on the multi-pattern matching algorithm, perform special verification on different types of values. For strings, check the closing of single quotes and the legality of escape characters. For numbers, verify whether they are legal numbers and check the range. For boolean values, strictly match true / false (case-sensitive). For dates, verify whether they conform to the preset format.

[0080] Verification target: Ensure that the values in the query conditions (such as strings, numbers) conform to the preset format, specifically including: strings must be wrapped with single quotes ('), and the escape characters are legal; numbers must not contain non-numeric characters (such as letters, special symbols, etc.).

[0081] Implementation method: Design special verification logics for different value types (strings, numbers) respectively, and combine regular expressions and state machines to achieve accurate verification. 1. String value format verification: Core rule: It must start and end with single quotes, and the single quotes in the middle content need to be processed by escape characters (\') (unescaped single quotes are prohibited).

[0082] Verification process:

[0083] 1. Parenthesis verification: i. Check the first and last characters: Verify whether the first character and the last character of the value are both single quotes ('), otherwise throw an exception "The string must be wrapped with single quotes" (for example, using double quotes in name eq "张三", the verification fails). ii. Check the legality of escape characters in the middle content: Traverse the characters between single quotes. If a single quote (') is encountered, check whether the previous character is an escape character (\): If the previous character is \, it is determined as a legal escape (such as \' in 'abc\'def' is a legal escape). If the previous character is not \, it is determined as an "unescaped single quote" and an exception is thrown (for example, the second' in 'abc'def' is unescaped, and the verification fails). iii. Check the integrity of escape characters: If an escape character (\) is encountered, check whether there is a valid escape character (\' or \\) after it. If there are other characters after the escape character (such as \a, \b), throw an exception "Illegal escape character".

[0084] 2. Numeric Value Format Validation: Core Rule: Must be a valid numeric format (supports integers, decimals, and negative numbers), and must not contain letters, Chinese characters, or special symbols (except for the minus sign - and the decimal point .). Validation Process: i. Regular Expression Matching: Use preset regular expressions (e.g., integer ^-?\d+$, decimal ^-?\d+\.\d+$) to match numeric value strings, excluding cases containing non-numeric characters (e.g., 123a, 45.6.7, and -89b do not match the regular expression). ii. Boundary Case Handling: The minus sign - is only allowed to appear at the beginning (e.g., -123 is valid, 12-3 is invalid). The decimal point . is only allowed to appear once (e.g., 123.45 is valid, 12.34.56 is invalid). iii. Utility Class Auxiliary Validation: Combine with numeric parsing tools (e.g., Java's NumberUtils.isCreatable()) for secondary validation to ensure that the string can be correctly parsed into numeric types (e.g., 123 can be parsed as Integer, 45.6 can be parsed as Double).

[0085] Validation objective: Ensure that the enumeration values ​​involved in the query conditions (such as a set of fixed values ​​preset by the business, such as order status ['Pending payment', 'Completed', 'Cancelled'], user level ['Normal', 'VIP', 'Diamond'], etc.) are valid values ​​in the preset set, and prohibit the use of undefined enumeration values.

[0086] Implementation method: Based on the preset set of enumerated values ​​and associated mapping, fast verification is achieved through table lookup.

[0087] Specific process: 1. Predefined enumeration value set: For enumeration type fields of business entities (such as Order.status, User.level), the corresponding enumeration value set is loaded during the system initialization phase and stored in the "field-enumeration value" mapping table (such as Map). <String, Set <string>> `fieldEnums`, where the key is the field name and the value is a collection of enumerated values ​​for that field, such as `fieldEnums.put("Order.status", {"Pending Payment", "Completed", "Cancelled"})`. 2. Related Validation Trigger: When the query condition involves an enumerated type field (such as `Order.status eq 'Pending Payment'`), extract the field name (`Order.status`) and the input value (`'Pending Payment'`): retrieve the corresponding enumerated value collection for that field from the mapping table (such as `{"Pending Payment", "Completed", "Cancelled"}`).

[0088] Check if the input value (after removing single quotes) exists in the enumeration value set: if it exists, it is determined to be a valid enumeration value and proceeds to the next step. If it does not exist, throw an exception and prompt "The enumeration value of field [Order.status] is invalid. Valid values ​​include: pending payment, completed, canceled".

[0089] 3. Dynamic expansion support: Supports dynamic updates of the enumeration value set through configuration files or API interfaces (such as adding an order status 'timeout'), expanding the validation scope without modifying the source code.

[0090] The syntax parsing module is used to perform syntax analysis on the verified token sequence and generate a standardized AST.

[0091] Based on a recursive descent parser, an initial AST is constructed according to preset syntax rules, including: expression → logical expression | comparison expression; logical expression → expression (AND|OR) expression | NOT expression; comparison expression → field (EQ|GT|LIKE) value | function (EQ|GT) value; function → function name '('field')'. The initial AST is then normalized by completing implicit precedence, unifying the value node format, merging consecutive identical logical nodes, and generating a standardized AST with a unified structure and no ambiguity.

[0092] The local specification module is used to generate local query specifications for each AST node based on the standardized AST. The method for traversing the AST nodes to generate local query specifications includes:

[0093] The system employs a depth-first traversal strategy to traverse the Abstract Syntax Tree (AST), assigning a unique ID to each node and calling the corresponding processor based on node type. The core process is as follows:

[0094] Node unique identifier allocation: Generate a unique ID for each node in the form of node-123 (generated based on an atomic counter); the ID is used for log tracking (such as recording the processing time and error location of each node).

[0095] Processor scheduling mechanism: Maintain a "node type → processor" mapping table (e.g., AND node → AndNodeProcessor), and dynamically call the corresponding processor according to the node type (implemented through the factory pattern).

[0096] Traversal strategy: Process child nodes first, then parent nodes (following the depth-first principle). This ensures that local query specifications for child nodes are generated first, providing a foundation for combining parent nodes.

[0097] For logical nodes (and / or / not), the left and right child nodes are processed recursively, and local specifications are combined; for logical operation nodes (such as AND, OR, NOT), the system adopts a recursive processing strategy.

[0098] AND node processing flow: Recursively process the left child node to obtain the left local specification (e.g., custLevel = 'VIP'). Recursively process the right child node to obtain the right local specification (e.g., orderAmount > 10000). Combine the two specifications using JPA's CriteriaBuilder.and() method. Generate a new specification representing "custLevel = 'VIP' AND orderAmount > 10000" OR node processing flow:

[0099] Similar to AND, but uses the CriteriaBuilder.or() method to combine specifications;

[0100] Generate a query in the form of "condition 1 OR condition 2";

[0101] NOT node processing flow: Recursively process child nodes and obtain child specifications (such as status = 'ACTIVE');

[0102] Invert the value using the CriteriaBuilder.not() method;

[0103] Generate a query in the form "NOT status = 'ACTIVE'".

[0104] For comparison nodes (eq / gt / like, etc.), the field name and value are parsed, the JPA method mapping is obtained from the rule center, and the field comparison specification is generated; for field comparison nodes (such as EQ, GT, LIKE), the system performs the following steps:

[0105] Field name parsing: Extract field names (e.g., custLevel) from the left child node;

[0106] Validate whether the field exists in the target entity (such as the Customer class);

[0107] Value parsing and validation: Extract the value from the right child node (e.g., 'VIP'); validate the value format (e.g., strings must be enclosed in single quotes);

[0108] JPA method mapping: Mapping operators to JPA methods through rule centers (e.g., EQ → CriteriaBuilder.equal()).

[0109] Generate JPA expressions (such as root.get("custLevel").equal("VIP")).

[0110] For function nodes (upper / lower, etc.), the function name and parameters are parsed, a function expression is generated, and the values ​​are combined and compared to ensure they are correct. For function call nodes (such as UPPER(name)), the system performs the following steps:

[0111] Function parsing: Extracting function names (e.g., UPPER) and parameters (e.g., the name field); validating function validity (whether it is a system-supported function); generating function expressions:

[0112] Map function names to JPA expressions through the rule center (e.g., UPPER → CriteriaBuilder.upper());

[0113] Generate function expressions (such as cb.upper(root.get("name")));

[0114] Combinatorial comparison logic: compares the function expression with the value on the right (e.g., = 'ZHANGSAN'); generates the complete specification (e.g., UPPER(name) = 'ZHANGSAN').

[0115] The execution object generation module is used to generate executable JPASpecification objects based on the local query specifications of each AST node.

[0116] Starting from the root node of the AST, local specifications are recursively merged according to the parent-child relationship of nodes, and pagination parameters and sorting parameters are embedded to generate an executable top-level JPA Specification object.

[0117] The type formatting module is used to call the JPA Specification object to execute database queries and perform type conversion on the query results. Methods for executing queries and formatting results include: calling the findAll method of JpaSpecificationExecutor to execute database queries, and caching frequently queried Specifications;

[0118] The query results are converted to JSON format, null values ​​are handled, and pagination is performed.

[0119] Query phase: Call the JpaSpecificationExecutor.findAll method.

[0120] Parameter preparation:

[0121] Input 1: The Specification object generated in step 6 (encapsulating the query conditions, such as custLevel eq 'VIP' and orderAmount gt 10000).

[0122] Input 2: A Pageable object (encapsulating pagination parameters, such as page=0 (page 1), size=10 (10 items per page), sort=orderTime,desc (sorted by order time in descending order)).

[0123] Execution logic:

[0124] JpaSpecificationExecutor is the core interface provided by Spring Data JPA, and its findAll(Specification) function... <t>The `spec, Pageable pageable)` method will:

[0125] Convert the Specification to JPA CriteriaQuery (based on the JPA Criteria API).

[0126] Add pagination (setFirstResult, setMaxResults) and sorting (orderBy) conditions based on Pageable.

[0127] Execute CriteriaQuery through EntityManager to generate the corresponding SQL statement (e.g., SELECT *FROM customer WHERE cust_level = 'VIP' AND order_amount > 10000 LIMIT 0,10).

[0128] After executing the SQL, the database returns a Page containing the entity objects. <t>Results (including pagination metadata and current page data).

[0129] Unified Data Types: The raw results returned by a database query may contain JPA entity objects, but some field types need to be converted to common business layer types (such as dates and enumerations). The processing rules are as follows:

[0130] Date type conversion: Convert the java.sql.Timestamp returned by the database to the Java 8 new date type LocalDateTime. Formula:

[0131] LocalDateTime result = sqlTimestamp.toLocalDateTime() (To avoid thread safety issues with java.util.Date, use types from the java.time package).

[0132] Enumeration type conversion: Convert the enumeration code stored in the database (e.g., 0 represents "pending payment") into an enumeration object (e.g., OrderStatus.PENDING) using the enumeration's fromCode method.

[0133] OrderStatus status = OrderStatus.fromCode(dbCode)

[0134] (fromCode is a custom method that internally matches the encoding with the enumeration object using a switch-case or mapping table).

[0135] Custom type conversion: For business-specific types (such as BigDecimal amounts requiring two decimal places), this can be achieved through the Converter interface:

[0136]

[0137] (2) Handling null values: Standardized null value representation:

[0138] For null values ​​in the results (such as user.getEmail() = null), the handling strategy is to retain null and explicitly mark it: keep null in the JSON (instead of omitting the field) to make it easier for the front end to determine "the field exists but has no value".

[0139] Replace with default value: Replace numeric types (such as age = null) with 0; replace string types (such as remark = null) with "" (empty string).

[0140] Special business handling: If a key field (such as id) is null, throw an exception (because the primary key cannot be null, it may be a query logic error).

[0141] (3) Pagination encapsulation: Integrating metadata and business data: The original Page <t>The object (returned by Spring Data JPA) is converted into a standardized pagination object StandardPage in the business layer, with the following structure:

[0142]

[0143] Total Pages Calculation: If the total number of items is totalItems and the number of items per page is pageSize, then the formula for the total number of pages is: totalPages = (totalItems + pageSize - 1) / pageSize (rounding up is achieved through integer operations to avoid floating-point precision issues).

[0144] (4) JSON serialization: Generate standardized JSON:

[0145] Use the Jackson library (Spring's default JSON processing library) to convert the StandardPage object to JSON. Key configuration: Field naming strategy: Convert Java camelCase (e.g., orderAmount) to JSON underscore naming (e.g., order_amount) through the @JsonProperty annotation or global configuration: objectMapper.setPropertyNamingStrategy(PropertyNamingStrategy.SNAKE_CASE).

[0146] Unified date format: Specify the JSON format of the date field (e.g., yyyy-MM-dd HH:mm:ss) using the @JsonFormat annotation: @JsonFormat(pattern="yyyy-MM-ddHH:mm:ss",timezone="GMT+8") (to avoid date display errors caused by time zone offset).

[0147] Ignore null fields (optional): Ignore fields with null values ​​by configuring them (e.g., remark = null should not be displayed in JSON): objectMapper.setSerializationInclusion(Include.NON_NULL).

[0148] The dynamic query and transformation module is used to receive new operator rules through a REST API based on the query results after type conversion, and complete the dynamic transformation of query conditions based on syntax parsing. The end-to-end monitoring and dynamic rule update methods include: collecting end-to-end logs such as token sequences, AST snapshots, transformation time, and SQL statements; monitoring metrics such as parsing success rate and P99 time; triggering alarms when thresholds are exceeded; receiving new operator or function rules through the REST API; updating memory configuration in real time; and supporting rule version rollback.

[0149] Example 2:

[0150] A dynamic query condition transformation method based on syntax parsing, the method includes:

[0151] During the Spring container startup phase, the support layer configuration is loaded and preset components are initialized.

[0152] Initialize the system context during the Spring container startup phase (CommandLineRunner execution phase), load the support layer configuration, including operator mapping rules (such as eq→equal, gt→greaterThan) and log monitoring parameters (parsing success rate threshold of 99.95%, P99 latency threshold of 100ms); initialize core components, including the lexical analysis state machine (pre-set DEFAULT / STRING / IDENTIFIER states and transition rules), the DFA validator (pre-loaded operator whitelist eq / and / or / gt / lt), and the JSqlParser syntax parsing engine (configured with custom syntax rules); register processors, including logic node processors (AndNodeProcessor / OrNodeProcessor), comparison node processors (EqNodeProcessor / GtNodeProcessor), and function node processors (UpperNodeProcessor).

[0153] Receive the original query string uploaded by the user and perform lexical analysis to generate a token sequence containing type and location information.

[0154] Lexical analysis is performed on the original query string passed in by the user to generate a Token sequence with type and position information. For example, for the query string "(custLevel eq 'VIP' and (orderAmount gt 10000))”, the state machine starts from the DEFAULT state, traverses the string character by character. When encountering "(", it generates an LPAREN Token (pos = 0). When encountering "custLevel", it enters the IDENTIFIER state and generates a FIELD Token (pos = 1). When encountering "eq", it generates an OPERATOR Token (pos = 12). When encountering "'VIP'", it enters the STRING state and generates a VALUE Token (pos = 15). The subsequent characters are processed in the same way, and finally a complete Token sequence is generated.

[0155] Traverse the token sequence and perform verification to obtain the verified token sequence.

[0156] Perform a legality check on the Token sequence. In the parentheses matching check, initialize an empty stack, traverse the Token sequence. When encountering an LPAREN, push it onto the stack and record the position. When encountering an RPAREN, pop the top element of the stack. If the stack is empty after traversal, the check passes. In the operator legality check, use a DFA to match the operators in the Token sequence. For illegal operators, such as "eqa", recommend "eq" through the edit distance algorithm. In the value format check, check the closing of single quotes for the string "'VIP'", and call NumberUtils.isCreatable to verify the format legality for the number "10000".

[0157] Perform syntax analysis on the verified token sequence to generate a standardized AST.

[0158] Based on the Token sequence that passes the verification, perform syntax parsing to generate a standardized AST. Based on a recursive descent parser, construct an initial AST according to the preset syntax rules. For the query condition "custName eq '张三' and age lt 18", generate an initial AST with the root node as AND_NODE and containing two COMPARISON_NODE child nodes. Perform normalization on the initial AST, complete the implicit precedence, convert the value node "18" to the Integer type, and merge consecutive identical logical nodes to generate a standardized AST (as Figure 2 shown).

[0159] Generate local query specifications for each AST node based on the standardized AST.

[0160] Traverse the AST nodes to generate local query specifications for each node. A depth-first traversal strategy is used to traverse the AST, assigning a unique ID to each node. For AND_NODE, recursively process the left and right child nodes, obtaining the left and right local specifications, and combining them into leftSpec.and(rightSpec). For the eq node (custLevel eq 'VIP'), parse the field name "custLevel" and the value "VIP", obtain the JPA method CriteriaBuilder.equal corresponding to eq from the rule center, and generate the specification "(root, query, cb) -> cb.equal(root.get("custLevel"), "VIP")".

[0161] An executable JPA Specification object is generated based on the local query specifications of each AST node.

[0162] Combine local query specifications to generate a complete JPA Specification. Starting from the root node of the AST, recursively merge local specifications according to parent-child relationships. For OR_NODE, combine the left subtree specification and the right subtree specification into leftSpec.or (rightSpec); embed pagination parameters (page number 0, 10 items per page) and sorting parameters (ascending order by custName) to generate an executable top-level JPA Specification object.

[0163] The JPA Specification object is invoked to perform a database query, and the query results are then type-converted.

[0164] Execute the query and format the results. Call JpaSpecificationExecutor.findAll(spec, pageable) to execute the database query, cache frequently queried Specifications (key is the query string + entity type, valid for 30 minutes); perform type conversion on the query results, converting dates to "yyyy-MM-dd" strings, uniformly retaining null identifiers for empty values, encapsulating pagination metadata (total number of records, total number of pages, etc.), and returning it in JSON format.

[0165] Based on the query results after type conversion, new operator rules are received via REST API to complete dynamic query condition conversion based on syntax parsing.

[0166] Perform end-to-end monitoring and dynamic rule updates. During the execution of steps S2-S7, synchronously collect end-to-end logs such as token sequences, AST snapshots, conversion time, and SQL statements (anonymized); monitor metrics such as parsing success rate and P99 time; trigger email alerts when the error rate exceeds 0.1% or the P99 time exceeds 200ms; receive new operator rules (such as adding the between operator) via REST API, update memory configuration in real time, and support rule version rollback.

[0167] The user inputs a query string, the lexical analysis module performs lexical analysis on it to generate a token sequence; the validation module performs legality validation on the token sequence, and after passing the validation, the syntax parsing module generates a standardized AST; the local specification generation module traverses the AST nodes to generate a local query specification; the specification combination module combines the local specifications to generate a complete JPA Specification; the execution and formatting module executes the query and returns the formatted result; the monitoring and update module performs full-link monitoring throughout the entire process and supports dynamic rule updates.

[0168] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made to the technical solutions of the present invention by those skilled in the art without departing from the spirit of the present invention should fall within the protection scope defined by the claims of the present invention.< / t> < / t> < / t> < / string>

Claims

1. A dynamic query condition conversion system based on syntax parsing, characterized by, The system comprises: An initialization module for loading a support layer configuration and initializing preset components in a Spring container startup phase; A lexical analysis module for receiving a user-uploaded original query string and performing lexical analysis to generate a token sequence containing type and position information; A sequence verification module for traversing the token sequence and performing verification to obtain a verified token sequence; A syntax analysis module for performing syntax analysis on the verified token sequence to generate a standardized AST; A local specification module for generating local query specifications of each AST node based on the standardized AST; An executable object generation module for generating executable JPA Specification objects based on the local query specifications of each AST node; A type formatting module for invoking the JPA Specification objects to execute database queries and performing type conversion on query results; A dynamic query and conversion module for receiving new operator rules through a REST API based on the type-converted query results to complete dynamic query condition conversion based on syntax analysis; In the initialization module, the support layer configuration comprises operator mapping rules and log monitoring parameters; The preset components comprise a lexical analysis state machine, a DFA verifier, an operator whitelist loader, a JSqlParser syntax analysis engine, and a registration processor; The workflow of the sequence verification module specifically comprises: Based on a stack data structure, the token sequence is traversed, and bracket matching is verified by checking LPAREN and RPAREN; Based on the token sequence, an OPERATOR type token is generated using lexical analysis, a string value of the OPERATOR type token is extracted, the string value is compared and matched with a preset operator hash table, and the legality of the token sequence is verified; The legality of value formats and enumerated values in the token sequence is verified; The process of verifying bracket matching by checking LPAREN and RPAREN specifically comprises: If LPAREN is encountered, it is pushed into the stack and the position is recorded, if RPAREN is encountered, it is checked whether the stack is empty, if it is empty, an exception is displayed, otherwise the top element of the stack is popped, after the traversal is completed, it is checked whether the stack is empty, if it is not empty, an exception signal is thrown.

2. A method for dynamic query condition conversion based on syntax parsing, the method applying the system of claim 1, characterized in that, The method comprises: In a Spring container startup phase, a support layer configuration is loaded, and preset components are initialized; A user-uploaded original query string is received and subjected to lexical analysis to generate a token sequence containing type and position information; The token sequence is traversed and verified to obtain a verified token sequence; The verified token sequence is subjected to syntax analysis to generate a standardized AST; Local query specifications of each AST node are generated based on the standardized AST; Executable JPA Specification objects are generated based on the local query specifications of each AST node; The JPA Specification object is called to perform a database query, and the query result is type-converted; Based on the type-converted query result, a new operator rule is received through a REST API, and a dynamic query condition conversion based on syntax analysis is completed. 3.The syntax parsing based dynamic query condition conversion method of claim 2, wherein, The support layer configuration includes operator mapping rules and log monitoring parameters; The preset components include a lexical analysis state machine, a DFA checker, a loaded operator white list, a JSqlParser syntax analysis engine and a registration processor. 4.The syntax parsing based dynamic query condition conversion method of claim 2, wherein, The process of traversing the token sequence and performing checking specifically includes: Based on a stack data structure, the token sequence is traversed, and bracket matching is checked by checking LPAREN and RPAREN. Based on the token sequence, an OPERATOR type token is generated using lexical analysis, a string value of the OPERATOR type token is extracted, the string value is compared and matched with a preset operator hash table, and the legality of the token sequence is checked. The legality of the value format and the enumerated value in the token sequence is checked.

5. The method of claim 4, wherein, The process of checking bracket matching by checking LPAREN and RPAREN specifically includes: If LPAREN is encountered, it is stacked and the position is recorded, if RPAREN is encountered, it is checked whether the stack is empty, if the stack is empty, an exception is displayed, otherwise, the top element of the stack is popped, after the traversal is completed, it is checked whether the stack is empty, if the stack is not empty, an exception signal is thrown.

Images