Dynamic query condition conversion system and method based on grammar analysis

Abstract

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

Description

Technical Field

[0001] The present invention relates to the technical field of enterprise-level application database query middleware, and in particular to a dynamic query condition conversion system and method based on syntax analysis. Background Art

[0002] As enterprises deepen their digital transformation, data-intensive applications are increasingly demanding dynamic queries. Current dynamic query solutions based on Spring Data JPA have several core architectural issues:

[0003] Module responsibilities are confused. Existing solutions embed 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 searching for "VIP customers with a purchase amount greater than 10,000" must be written directly in the customer management module. Changes to the query conditions require modifications to the source code of the business module, resulting in high maintenance costs.

[0004] The syntax is closed, requiring hard-coded implementations of supported query operators (such as equality, greater than, and fuzzy matching). Adding new operators (such as "contained in list") requires modifying the core conversion logic. For example, in the jpa-spec library, supporting the "in" operator requires adding a dedicated in() method and modifying the expression processing logic, resulting in poor scalability.

[0005] Entity adaptation is cumbersome, requiring repeated development of conversion logic for queries against different business entities (such as Customer, Order, and Product). For example, a customer query requires writing a CustomerSpecification, while an order query requires writing an OrderSpecification. This results in a large amount of duplicated code and low development efficiency.

[0006] There are significant scalability bottlenecks. The complexity of query conditions is limited by predefined logic during development, and it cannot support complex user-defined combination conditions (such as multi-nested logic (A and B) or (C and (D or E)). To support this, the expression parsing logic must be restructured, which is highly risky.

[0007] Troubleshooting is difficult because query logic is scattered across various business modules. When abnormal query results occur, the Specification construction logic in the business code must be checked one by one, resulting in a long troubleshooting cycle (average troubleshooting time is approximately 2 hours per time).

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

[0009] To solve the above technical problems, the application provides a dynamic query condition conversion system and method based on syntax analysis, and the system specifically comprises:

[0010] An initialization module is configured to load a support layer configuration and initialize preset components in a Spring container startup phase.

[0011] A lexical analysis module is configured to receive an original query string uploaded by a user and perform lexical analysis to generate a token sequence containing type and position information.

[0012] A sequence verification module is configured to traverse the token sequence and perform verification to obtain a verified token sequence.

[0013] A syntax analysis module is configured to perform syntax analysis on the verified token sequence to generate a standardized AST.

[0014] A local specification module is configured to generate local query specifications of AST nodes based on the standardized AST.

[0015] An execution object generation module is configured to generate executable JPASpecification objects based on the local query specifications of the AST nodes.

[0016] A type formatting module is configured to call the JPASpecification objects to perform database query and convert the query results.

[0017] A dynamic query and conversion module is configured to receive new operator rules through a REST API based on the converted query results, and complete dynamic query condition conversion based on syntax analysis.

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

[0019] The preset components comprise a lexical analysis state machine, a DFA verifier, a loaded operator whitelist, a JSqlParser syntax analysis engine and a registration processor.

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

[0021] Based on a stack data structure, the token sequence is traversed, and bracket matching is verified by checking LPAREN and RPAREN.

[0022] Based on the token sequence, generate an OPERATOR type token using lexical analysis, extract the string value of the OPERATOR type token, compare and match the string value with a preset operator hash table, and perform operator validity verification on the token sequence;

[0023] Verify the validity of the value format and enumeration values ​​in the token sequence.

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

[0025] If LPAREN is encountered, it is pushed onto the stack and the position is recorded. If RPAREN is encountered, it is checked whether the stack is empty. If it is an empty stack, an exception is displayed. Otherwise, the top element of the stack is popped out. After the traversal is completed, it is checked whether the stack is empty. If it is not an empty stack, an exception signal is thrown.

[0026] The present invention also discloses a method for dynamic query condition conversion based on grammatical analysis, the method comprising:

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

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

[0029] Traversing the token sequence and verifying it to obtain a verified token sequence;

[0030] Performing grammatical analysis on the verified token sequence to generate a standardized AST;

[0031] Generate a local query specification for each AST node based on the standardized AST;

[0032] Generate an executable JPA Specification object based on the local query specification of each AST node;

[0033] Call the JPA Specification object to execute database query and perform type conversion on the query result;

[0034] Based on the query results after type conversion, new operator rules are received through the 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 component includes a lexical analysis state machine, a DFA checker, a load operator white list, a JSqlParser syntax parsing engine and a registration processor.

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

[0038] Based on a stack data structure, the token sequence is traversed, and bracket matching is checked by checking LPAREN and RPAREN.

[0039] Based on the token sequence, an OPERATOR type token is generated by 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 operation compliance of the token sequence is checked.

[0040] The value format and enumerated value in the token sequence are checked for legality.

[0041] Optionally, the process of checking bracket matching by checking LPAREN and RPAREN specifically includes:

[0042] 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.

[0043] Compared with the prior art, the present application has the following beneficial effects:

[0044] By separating the query logic from the business module, the present application realizes complete decoupling of the business module and the query logic, and can reduce the data access code amount in the business module by 30% to 50%; the business developer does not need to learn JPACriteria API, the development cycle of the new business entity accessing the query function is shortened from the original 2 days to 2 hours, and the development efficiency is greatly improved; when a new operator is added, only the mapping relationship needs to be added in the rule configuration center, the development workload is reduced by 80%, the scalability is significantly enhanced; the user can dynamically configure multiple nested query conditions (up to 8 layers), and the complex business scenario requirements are met; the query logic is concentrated in the engine module, the complete processing link can be tracked through the log monitoring module for troubleshooting, the average troubleshooting time is shortened from 4 hours to 30 minutes, and the maintenance cost is reduced. BRIEF DESCRIPTION OF DRAWINGS

[0045] In order to more clearly illustrate the technical solution of the present invention, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0046] Figure 1 This is a system structure diagram of a dynamic query condition conversion system based on syntax analysis provided by an embodiment of the present invention;

[0047] Figure 2 This is an example diagram of the AST node structure provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0048] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the present invention is 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 grammatical unit obtained after lexical analysis, containing type, value, and position information;

[0051] AST (Abstract Syntax Tree): used to represent the grammatical structure of query conditions and reflect the logical hierarchy of query conditions;

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

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

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

[0055] Example 1:

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

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

[0058] During the Spring container startup phase (CommandLineRunner execution period), 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 is used to receive the original query string uploaded by the user and perform lexical analysis to generate a token sequence containing type and position information. The lexical analysis methods include:

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

[0061] The state switching rules include:

[0062] When encountering "(" or ")", an LPAREN or RPAREN token is generated and the state remains in "DEFAULT". When encountering a single quote "'", the state enters the "STRING" state, reads until 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 state enters the "IDENTIFIER" state, reads consecutive characters, generates a FIELD or OPERATOR token, and switches back to the "DEFAULT" state when encountering a character other than a letter, a number, or an underscore. When encountering a number or a minus sign "-", the state 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-number or decimal point character.

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

[0064] Methods for validating the Token sequence include:

[0065] Bracket matching check: Based on the stack data structure, the token sequence is traversed. When an LPAREN is encountered, it is pushed onto the stack and the position is recorded. When an RPAREN is encountered, the stack is checked to see if it is empty. If the stack is empty, an "extra close bracket" exception is thrown. If it is not empty, the top element of the stack is popped. After the traversal, if the stack is not empty, an "unclosed bracket" exception is thrown.

[0066] Verification objective: Ensure that the number of left parentheses (()) and right parentheses ()) in the query conditions is equal and that the nesting relationship is legal (that is, each left parenthesis is closed by a corresponding right parenthesis, and there is no cross-nesting or unclosed situation).

[0067] Implementation method: Based on the stack data structure, it traverses the token sequence of the query condition (such as LPAREN (left bracket) and RPAREN (right bracket) type tokens generated by lexical analysis) and executes the push and pop logic to verify the nesting legitimacy.

[0068] Specific process:

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

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

[0071] 221. If the stack is empty, it means there is an "extra right bracket" and an exception is thrown (e.g., "There is an unmatched right bracket at position x"). 222. If the stack is not empty, pop the top element (i.e., the corresponding left bracket position) and mark it as "successfully closed". 223. End of traversal verification:

[0072] 2231. If the stack is empty, it means that all left brackets have been closed and the match is legal. 2232. If the stack is not empty, it means that there is an "unclosed left bracket" and an exception is thrown (e.g. "The left bracket at position y is unclosed").

[0073] Example: Valid case: (A and (B or C)) → During the traversal, left brackets are pushed onto the stack and right brackets are popped off the stack, until the stack is empty and verification passes. Invalid case: (A and (B or C) → After the traversal, one left bracket remains unclosed on the stack, so verification fails. (A and B) or (C and D) → Similarly, the stack is not empty and verification fails.

[0074] Operator validity verification: Based on a deterministic finite automaton (DFA), the operator whitelist is preloaded and a DFA state transition table is constructed. The operator type token is traversed and the token value is input into the DFA. If the operator does not reach the accepting state, it is considered an illegal operator. The edit distance algorithm is used to recommend the closest legal operator. The verification goal is to ensure that the operators used in the query conditions are all legal operators preset by the system (such as eq (equal to), ne (not equal to), gt (greater than), lt (less than), ge (greater than or equal to), le (less than or equal to), like (fuzzy matching), in (included in), and (logical AND), or (logical OR), not (logical NOT)). Undefined operators (such as eqa and lik) are prohibited.

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

[0076] Specific process: 1. Preset operator set definition: Preset operators are loaded through the configuration file or during system initialization and stored in a hash table (HashSet) to achieve fast O(1) time complexity queries (e.g., validOperators = {"eq", "ne", "gt", ..., "not"}). 2. Token-level validation: After lexical analysis generates an OPERATOR type token, extract the token's string value (e.g., "eqa") and check whether it exists in the preset operator set. If so, it is determined to be a valid operator and proceeds to the next step. If not, it is determined to be an illegal operator and triggers exception handling.

[0077] 3. Exception handling and optimization: Throw an exception and clearly prompt "Illegal operator: xxx, supported operators include: eq, ne, gt...".

[0078] To improve the user experience, we use an edit distance algorithm (such as Levenshtein distance) to calculate the similarity between illegal operators and predefined operators, and recommend the most likely legal operator. (For example, if the edit distance between the illegal operator "eqa" and "eq" is 1, "eq" is recommended.) Example: Legal case: custName eq '张三', eq is a predefined operator, and verification passes. Illegal case: orderAmount eqa 1000, eqa is not in the predefined set, and verification fails with the message "Illegal operator eqa, eq recommended."

[0079] Value format verification: Based on a multi-pattern matching algorithm, special verification is performed on different types of values. Strings must be checked for single quote closure and escape legality. Numbers must be verified for legality and their ranges. Boolean values ​​must strictly match true / false (case-sensitive). Dates must be verified for compliance with the preset format.

[0080] Verification objective: Ensure that the values ​​in the query conditions (such as strings and numbers) conform to the preset format. Specifically, strings must be enclosed in single quotes (') and have valid escape sequences; numbers cannot contain non-numeric characters (such as letters and special symbols).

[0081] Implementation: Design dedicated validation logic based on value type (string, number), combining regular expressions with state machines for precise validation. 1. String value format validation: Core rule: Must begin and end with single quotes, and single quotes within the string must be escaped (\'). Unescaped single quotes are prohibited.

[0082] Verification process:

[0083] 1. Bracket Verification: i. Checking the first and last characters of the value: Verify that both the first and last characters are single quotes ('). If not, a "String must be enclosed in single quotes" exception is thrown (for example, if double quotes are used in name eq "张三", the verification fails). ii. Checking the validity of escape sequences within the content: Iterate through the characters between the single quotes. If a single quote (') is encountered, check whether the preceding character is an escape character (\). If the preceding character is a \, it is considered a legal escape (for example, the \' in 'abc\'def' is a legal escape). If the preceding character is not a \, it is considered an "unescaped single quote" and an exception is thrown (for example, the second ' in 'abc'def' is not escaped, the verification fails). iii. Checking the integrity of escape sequences: If an escape sequence (\) is encountered, check whether a valid escape sequence follows (only \' or \\ is supported). If the escape sequence is followed by other characters (for example, \a or \b), an "illegal escape sequence" exception is thrown.

[0084] 2. Numeric Value Format Verification: Core Rules: Must be a valid numeric format (supporting integers, decimals, and negative numbers). Letters, Chinese characters, and special symbols (except the minus sign - and decimal point .) are prohibited. Verification Process: i. Regular Expression Matching: Uses preset regular expressions (such as ^-?\d+$ for integers and ^-?\d+\.\d+$ for decimals) to match numeric strings, excluding those containing non-numeric characters (e.g., 123a, 45.6.7, and -89b all fail to match these regular expressions). ii. Edge Case Handling: The minus sign - is only allowed to appear as the first character (e.g., -123 is legal, 12-3 is illegal). The decimal point . is only allowed to appear once (e.g., 123.45 is legal, 12.34.56 is illegal). iii. Utility-Assisted Verification: Combined with numeric parsing tools (such as Java's NumberUtils.isCreatable()), secondary verification is performed to ensure that the string can be correctly parsed as a numeric type (e.g., 123 is parsed as an Integer, 45.6 is parsed as a Double).

[0085] Verification goal: Ensure that the enumeration values ​​involved in the query conditions (such as a fixed value set 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. Undefined enumeration values ​​are prohibited.

[0086] Implementation method: Based on the preset enumeration value set and associated mapping, fast verification is achieved through table lookup method.

[0087] Specific process: 1. Pre-definition of enumeration value set: For the 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 the enumeration value set for that field, such as fieldEnums.put("Order.status", {"To be paid", "Completed", "Cancelled"})). 2. Association validation trigger: When the query condition involves an enumeration type field (such as Order.status eq 'To be paid'), extract the field name (Order.status) and input value ('To be paid'): obtain the enumeration value set corresponding to the field from the mapping table (such as {"To be paid", "Completed", "Cancelled"}).

[0088] Checks whether the input value (after removing the single quotes) exists in the enumeration value set. If so, it is considered a valid enumeration value and proceeds to the next step. If not, an exception is thrown with the message "The enumeration value for the field [Order.status] is invalid. Valid values ​​include: pending, completed, and canceled."

[0089] 3. Dynamic expansion support: Support dynamic updates of enumeration value sets (such as adding the order status 'timed out') through configuration files or API interfaces, and expand the verification 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 the recursive descent parser, the initial AST is constructed according to the preset grammar rules. The grammar rules include: 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 normalized, implicit priority is completed, the value node format is unified, and consecutive identical logical nodes are merged to generate a standardized AST with unified structure and no ambiguity.

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

[0093] The system uses a depth-first traversal strategy to traverse the AST, assigning a unique ID to each node and calling the corresponding processor according to the node type. The system uses a depth-first traversal (DFS) strategy to traverse the abstract syntax tree (AST). The core process is as follows:

[0094] Node unique identifier allocation: A unique ID such as node-123 is generated for each node (generated based on the atomic counter's auto-increment). 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 (such as AND node → AndNodeProcessor), and dynamically call the corresponding processor based on the node type (implemented through the factory pattern).

[0096] Traversal strategy: process child nodes first, then parent nodes (according to the depth-first principle). Ensure that local query specifications for child nodes are generated first, providing a basis for parent node combination.

[0097] For logic nodes (and / or / not), the left and right child nodes are processed recursively to combine local specifications. For logic 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 combines criteria using the CriteriaBuilder.or() method;

[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 (e.g., status = 'ACTIVE');

[0102] Negate it through the CriteriaBuilder.not() method;

[0103] Generates queries of the form "NOT status = 'ACTIVE'".

[0104] For comparison nodes (such as eq / gt / like), the system parses the field name and value, obtains the JPA method mapping from the rule center, and generates the field comparison specification. For field comparison nodes (such as EQ, GT, LIKE), the system performs the following steps:

[0105] Field name parsing: extract the field name (such as custLevel) from the left child node;

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

[0107] Value parsing and verification: extract the value from the right child node (such as 'VIP'); verify the validity of the value format (such as strings must be wrapped in single quotes);

[0108] JPA method mapping: Mapping operators to JPA methods via rule-centric mapping (e.g. EQ → CriteriaBuilder.equal());

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

[0110] For function nodes (upper / lower, etc.), the system parses the function name and parameters, generates a function expression, and combines the values ​​for comparison. For function call nodes (such as UPPER(name)), the system performs the following steps:

[0111] Function parsing: extracting function names (such as UPPER) and parameters (such as the name field); verifying function validity (whether it is a function supported by the system); generating function expressions:

[0112] Mapping function names to JPA expressions via rule centers (e.g. UPPER → CriteriaBuilder.upper());

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

[0114] Combines comparison logic: compares the function expression with the right-hand value (such as = 'ZHANGSAN'); generates a complete specification (such as UPPER(name) = 'ZHANGSAN').

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

[0116] Starting from the AST root node, recursively merge local specifications according to the node parent-child relationship, embed paging parameters and sorting parameters, and generate an executable top-level JPA Specification object.

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

[0118] Perform type conversion, null value processing, and paging encapsulation on the query results, and convert them into JSON format.

[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: Pageable object (encapsulates paging parameters, such as page=0 (page 1), size=10 (10 items per page), sort=orderTime,desc (order by order time in descending order)).

[0123] Execution logic:

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

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

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

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

[0128] After the database executes the SQL, it returns the Page containing the entity object <t>Results (including paging metadata and current page data).

[0129] Unified data types: The original results returned by the database query may contain JPA entity objects, but some field types need to be converted to common types in the business layer (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 new Java 8 date type LocalDateTime. Formula:

[0131] LocalDateTime result = sqlTimestamp.toLocalDateTime() (avoiding thread safety issues of java.util.Date and uniformly using types in the java.time package).

[0132] Enumeration type conversion: Convert the enumeration code stored in the database (such as 0 for "pending payment") to an enumeration object (such as OrderStatus.PENDING) through the enumeration's fromCode method:

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

[0134] (fromCode is a custom method that internally matches the code and enumeration object through switch-case or mapping table).

[0135] Custom type conversion: For business-specific types (such as the amount BigDecimal needs to retain 2 decimal places), it is implemented through the Converter interface:

[0136]

[0137] (2) Null value processing: Standardized null value representation:

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

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

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

[0141] (3) Paging encapsulation: Integrate metadata and business data: <t>The object (returned by Spring Data JPA) is converted to the business layer standardized paging object StandardPage, structure:

[0142]

[0143] Calculation of total number of pages: If the total number of items is totalItems and the number of items per page is pageSize, then the total number of pages is calculated as: totalPages = (totalItems + pageSize - 1) / pageSize (rounding up is achieved through integer arithmetic 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 camel case naming (such as orderAmount) to JSON underscore naming (such as 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 (such as yyyy-MM-dd HH:mm:ss) through the @JsonFormat annotation: @JsonFormat(pattern="yyyy-MM-ddHH:mm:ss",timezone="GMT+8") (to avoid date display errors caused by time zone offsets).

[0147] Ignore empty value fields (optional): Ignore fields with null values ​​by configuration (such as remark = null is not displayed in JSON): objectMapper.setSerializationInclusion(Include.NON_NULL).

[0148] The dynamic query and conversion module receives new operator rules via the REST API based on query results after type conversion, completing dynamic query condition conversion based on syntax parsing. Full-link monitoring and dynamic rule updates include: collecting full-link logs such as token sequences, AST snapshots, conversion times, and SQL statements; monitoring metrics such as parsing success rate and P99 time; and triggering alerts when thresholds are exceeded. New operator or function rules are received via the REST API, memory configurations are updated in real time, and rule version rollbacks are supported.

[0149] Example 2:

[0150] A dynamic query condition conversion method based on grammar parsing, the method comprising:

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

[0152] Initialize the system context. During the Spring container startup phase (CommandLineRunner execution period), 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 time threshold of 100ms); initialize core components, including the lexical analysis state machine (preset DEFAULT / STRING / IDENTIFIER and other states and conversion rules), the DFA validator (preload the operator whitelist eq / and / or / gt / lt), and the JSqlParser syntax parsing engine (configure custom syntax rules); register processors, including logic node processors (AndNodeProcessor / OrNodeProcessor), comparison node processors (EqNodeProcessor / GtNodeProcessor), and function node processor (UpperNodeProcessor).

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

[0154] The original query string passed in by the user is lexically analyzed 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 in the DEFAULT state and traverses the string character by character. When it encounters "(", it generates an LPAREN token (pos=0). When it encounters "custLevel", it enters the IDENTIFIER state and generates a FIELD token (pos=1). When it encounters "eq", it generates an OPERATOR token (pos=12). When it encounters "'VIP'", it enters the STRING state and generates a VALUE token (pos=15). Subsequent characters are processed similarly, ultimately generating a complete token sequence.

[0155] The token sequence is traversed and verified to obtain a verified token sequence.

[0156] Verify the validity of token sequences. For bracket matching, initialize an empty stack, traverse the token sequence, and push each LPAREN element onto the stack and record the position. For RPAREN, pop the top element from the stack. If the stack is empty after traversal, verification passes. For operator validity, use a DFA to match operators in the token sequence. For illegal operators, such as "eqa," use an edit distance algorithm to recommend "eq." For value format verification, verify the closing of single quotes for the string "'VIP'" and call NumberUtils.isCreatable on the number "10000" to verify format validity.

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

[0158] Based on the verified token sequence, syntax parsing is performed to generate a standardized AST. Based on the recursive descent parser, the initial AST is constructed according to the preset grammatical rules. For the query condition "custName eq ' 张三' and age lt18", an initial AST with the root node AND_NODE and two COMPARISON_NODE child nodes is generated. The initial AST is normalized to complete the implicit priority, convert the value node "18" to Integer type, merge consecutive identical logical nodes, and generate a standardized AST (such as Figure 2 shown).

[0159] A local query specification for each AST node is generated based on the standardized AST.

[0160] Traverse the AST nodes and generate local query specifications for each node. Use a depth-first traversal strategy to traverse the AST, assigning each node a unique ID. For AND_NODE, recursively process the left and right child nodes to obtain the left and right local specifications, 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, generating the specification "(root, query, cb) -> cb.equal(root.get("custLevel"), "VIP")".

[0161] Generate an executable JPA Specification object based on the local query specification of each AST node.

[0162] Combine partial query specifications to generate a complete JPA Specification. Starting from the AST root node, recursively merge partial specifications based on parent-child relationships. For OR_NODE, combine the left subtree specification with the right subtree specification as leftSpec.or (rightSpec). Embed paging parameters (page number 0, 10 items per page) and sorting parameters (in ascending order by custName) to generate an executable top-level JPA Specification object.

[0163] The JPA Specification object is called to execute a database query and perform type conversion on the query result.

[0164] Execute the query and format the results. Call JpaSpecificationExecutor.findAll(spec, pageable) to execute the database query and 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, retaining null values, encapsulating paging metadata (total number of entries, total number of pages, etc.), and returning them in JSON format.

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

[0166] Perform full-link monitoring and dynamic rule updates. During steps S2-S7, synchronize and collect full-link logs, including token sequences, AST snapshots, conversion times, and SQL statements (massage). Monitor metrics such as parsing success rate and P99 time. Email alerts are triggered when the error rate exceeds 0.1% or the P99 time exceeds 200ms. New operator rules (such as the addition of a between operator) are received via the REST API, memory configurations are updated in real time, and rule version rollbacks are supported.

[0167] The user enters a query string, and the lexical analysis module performs lexical analysis on it to generate a token sequence; the verification module verifies the legitimacy of the token sequence. After passing the verification, the syntax parsing module generates a standardized AST; the local specification generation module traverses the AST nodes and generates local query specifications; the specification combination module combines 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 descriptions of preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Without departing from the spirit of the present invention, various modifications and improvements made to the technical solutions of the present invention by persons skilled in the art should fall within the scope of protection defined by the claims of the present invention.< / t> < / t> < / t> < / string>

Claims

1. A dynamic query condition conversion system based on syntax analysis, characterized in that: The system comprises: Initialization module, used to load support layer configuration and initialize preset components during the Spring container startup phase; The lexical analysis module is used to receive the original query string uploaded by the user and perform lexical analysis to generate a token sequence containing type and position information; A sequence verification module is used to traverse the token sequence and verify it to obtain a verified token sequence; A syntax parsing module, used to perform syntax analysis on the verified token sequence and generate a standardized AST; A local specification module, configured to generate a local query specification for each AST node based on the standardized AST; An execution object generation module, configured to generate an executable JPASpecification object based on the local query specification of each AST node; A type formatting module is used to call the JPA Specification object to execute database queries and perform type conversion on query results; The dynamic query and conversion 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 conversion based on syntax parsing.

2. The dynamic query condition conversion system based on syntax analysis according to claim 1 is characterized in that: In the initialization module, 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 load operator whitelist, a JSqlParser syntax parsing engine, and a registration processor.

3. The dynamic query condition conversion system based on syntax analysis according to claim 1 is characterized in that: The workflow of the sequence verification module specifically includes: Based on the stack data structure, traverse the token sequence and verify the bracket matching by checking LPAREN and RPAREN; Based on the token sequence, generate an OPERATOR type token using lexical analysis, extract the string value of the OPERATOR type token, compare and match the string value with a preset operator hash table, and perform operator validity verification on the token sequence; Verify the validity of the value format and enumeration values ​​in the token sequence.

4. The dynamic query condition conversion system based on syntax analysis according to claim 3 is characterized in that: The process of checking bracket matching by checking LPAREN and RPAREN is as follows: If LPAREN is encountered, it is pushed onto the stack and the position is recorded. If RPAREN is encountered, it is checked whether the stack is empty. If it is an empty stack, an exception is displayed. Otherwise, the top element of the stack is popped out. After the traversal is completed, it is checked whether the stack is empty. If it is not an empty stack, an exception signal is thrown.

5. A method for dynamic query condition conversion based on syntax analysis, said method applying the system according to any one of claims 1 to 4, characterized in that: Methods include: During the Spring container startup phase, the support layer configuration is loaded and the preset components are initialized; Receive the original query string uploaded by the user and perform lexical analysis to generate a token sequence containing type and position information; Traversing the token sequence and verifying it to obtain a verified token sequence; Performing grammatical analysis on the verified token sequence to generate a standardized AST; Generate a local query specification for each AST node based on the standardized AST; Generate an executable JPA Specification object based on the local query specification of each AST node; Call the JPA Specification object to execute database query and perform type conversion on the query result; Based on the query results after type conversion, new operator rules are received through the REST API to complete dynamic query condition conversion based on syntax parsing.

6. The method for dynamic query condition conversion based on syntax analysis according to claim 5, characterized in that: 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 load operator whitelist, a JSqlParser syntax parsing engine, and a registration processor.

7. The method for dynamic query condition conversion based on syntax analysis according to claim 5, characterized in that: The process of traversing the token sequence and performing verification specifically includes: Based on the stack data structure, traverse the token sequence and verify the bracket matching by checking LPAREN and RPAREN; Based on the token sequence, generate an OPERATOR type token using lexical analysis, extract the string value of the OPERATOR type token, compare and match the string value with a preset operator hash table, and perform operator validity verification on the token sequence; Verify the validity of the value format and enumeration values ​​in the token sequence.

8. The method for dynamic query condition conversion based on syntax analysis according to claim 7, characterized in that: The process of checking bracket matching by checking LPAREN and RPAREN is as follows: If LPAREN is encountered, it is pushed onto the stack and the position is recorded. If RPAREN is encountered, it is checked whether the stack is empty. If it is an empty stack, an exception is displayed. Otherwise, the top element of the stack is popped out. After the traversal is completed, it is checked whether the stack is empty. If it is not an empty stack, an exception signal is thrown.

Images