A structured query language query method, system, device and medium

Abstract

The application belongs to the technical field of data query, and discloses a structured query language query method, system, device and medium, the method comprising: receiving a starting data object, creating and binding a root query object of a current project identifier through a script entry method; establishing a field mapping from a field type to a field type operator; calling a corresponding field type operator according to the field type to perform parsing to return a field value or generate an associated subordinate query object; parsing a closure source code into an abstract syntax tree, traversing the abstract syntax tree to distinguish a field path and a runtime parameter value, generating a linear intermediate calculation unit, and reducing the intermediate calculation unit to form a structured filtering model; compiling a query load, generating an executable structured query language statement and executing to obtain a query result. The application uses Groovy dot syntax and closure expression to describe a query condition, and the expression mode is close to a business language, so that the learning cost is low.

Description

Technical Field

[0001] This invention relates to the field of data query technology, and in particular to a query method, system, device and medium for a structured query language. Background Technology

[0002] In low-code platforms, form-based business systems, and relational data management systems, business data typically exists in the form of dynamic entities, dynamic fields, and cross-entity references. Developers or platform configuration personnel often need to perform conditional searches, unique object location, and multi-level relational data extraction on master tables, referencing tables, child tables, and multi-valued related objects.

[0003] Existing implementation methods mainly include the following categories: 1. Developers manually write SQL (Structured Query Language) statements, using string concatenation to express conditions, join conditions, and subquery logic. 2. Using ORM, CriteriaAPI, QueryDSL, or similar frameworks to construct condition expressions via programming interfaces. 3. Using JSON condition structures defined internally by the platform or front-end filtering models, which are then interpreted and executed by the back-end query engine.

[0004] The above solutions have the following drawbacks and shortcomings: 1. Manually concatenated SQL has poor readability, is prone to injection risks, field errors, and incorrect bracket priority, and is not conducive to maintaining complex business rules. 2. Although ORM or Criteria API avoids some string concatenation problems, expressing deep relationships, nested exists / not exists, and sub-table filtering is still relatively cumbersome. 3. Fields and entities in dynamic form systems are usually driven by metadata, and field definitions are not fixed Java class attributes, making it difficult for traditional static ORM models to adapt. 4. Multi-level reference queries often require explicitly writing multiple query logic segments, making it difficult to support intuitive business expressions such as objects, related objects, and sub-related objects. 5. For high-frequency business conditions such as '_contains', '_in', '_between', '_exists', and '_notExists', existing methods usually lack a unified, concise, and nestable expression syntax. 6. When query conditions simultaneously contain constants, runtime variables, nested closures, and multi-level attribute access, traditional solutions are difficult to parse uniformly. 7. Existing technologies often treat object navigation and query condition construction separately, making it impossible to locate a unique object in the same expression before continuing to navigate to lower-level related objects.

[0005] Therefore, how to provide a query method, system, device, and medium for a structured query language is an urgent problem to be solved. Summary of the Invention

[0006] This invention provides a query method, system, device, and medium for a structured query language to solve the problems mentioned above in the prior art.

[0007] According to a first aspect of the present invention, a query method using a structured query language is provided.

[0008] In one embodiment, the query method of the structured query language includes: Receive the initial data object, and create and bind the root query object of the current project identifier through the script entry method; The entity context is initialized with the root query object as the current query object, and the entity field metadata corresponding to the target entity is loaded to establish a field mapping from field type to field type operator; In response to the script's access to the properties of the current query object, the field type of the accessed property in the field mapping is distinguished through dynamic property interception; and the corresponding field type operator is called to perform parsing based on the field type to return the field value or generate the associated sub-query object; When the lower-level query object calls the filtering method and passes in the closure, the closure source code is parsed into an abstract syntax tree. The abstract syntax tree is traversed to distinguish between field paths and runtime parameter values, generating linear intermediate calculation units. The intermediate calculation units are then reduced to form a structured filtering model. Extract the identifier set of each object in the data object set of the lower-level query object, construct the scope filtering conditions, and combine the structured filtering model with the scope filtering conditions into a query payload; The query payload is compiled to generate an executable structured query language statement, which is then executed to obtain the query results. Depending on the query result type, the query results can be encapsulated into a new query object that supports continued navigation, or converted into a standardized list of results and returned.

[0009] In one embodiment, a query system using a structured query language includes: The query entry construction module is used to receive the initial data object and create and bind the root query object of the current project identifier through the script entry method; The initialization loading module is used to initialize the entity context with the root query object as the current query object, load the entity field metadata corresponding to the target entity, and establish a field mapping from field type to field type operator; The dot syntax navigation module is used to respond to the script's access to the properties of the current query object. It distinguishes the field type of the accessed property in the field mapping through dynamic property interception; and calls the corresponding field type operator to perform parsing based on the field type to return the field value or generate the associated sub-query object. The filter model generation module is used to parse the closure source code into an abstract syntax tree when the lower-level query object calls the filter method and passes in the closure. It traverses the abstract syntax tree to distinguish field paths and runtime parameter values, generates linear intermediate calculation units, and reduces the intermediate calculation units to form a structured filter model. The query payload construction module is used to extract the identifier set of each object in the data object set of the lower-level query object, construct the scope filtering conditions, and combine the structured filtering model and the scope filtering conditions into the query payload. The backend compilation and execution module is used to compile the query payload, generate an executable structured query language statement, and execute it to obtain the query results; The result feedback parsing module is used to encapsulate the query results into a new query object that supports continued navigation, or to convert them into a standardized result list and return them, depending on the query result type.

[0010] According to a third aspect of the present invention, a computer device is provided.

[0011] In some embodiments, the computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the query method of the structured query language described above.

[0012] According to a fourth aspect of the present invention, a computer-readable storage medium is provided.

[0013] In one embodiment, a computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the steps of the query method of the structured query language described above.

[0014] The technical solutions provided by the embodiments of this invention can include the following beneficial effects: This invention uses Groovy dot syntax and closure expressions to describe query conditions, with an expression method close to business language and a low learning cost; based on entity field metadata and dynamic attribute interception, it is naturally adapted to dynamic forms, dynamic entities, and dynamic field scenarios; it uniformly processes basic fields, reference fields, and sub-table fields through field type operators, making multi-level related navigation more natural; based on GroovyAST rather than string templates for parsing, it can more accurately preserve comparison relationships, bracket structures, operator semantics, and nested expressions; it supports recursive related subqueries such as '_exists' and '_notExists', suitable for modeling complex hierarchical business relationships; it supports constant, runtime variables, multi-level object variables, collection variables, and nested Map / List parameter binding; through left and right value recognition algorithms, it can distinguish field paths from runtime parameter paths. Improves parsing accuracy in dynamic parameter binding scenarios; ensures correct query scope after each navigation by using scope ID set constraints, avoiding cross-level errors that amplify the query scope; supports continued navigation after '_findOne', achieving a combination of unique object location and downward object chained query capability; the underlying layer does not simply concatenate SQL, but first generates a structured QueryPayload, and then generates pre-compiled SQL through the backend compilation chain, which is convenient for expansion, verification and unified execution; compared with solutions based solely on dynamic SQL configuration or condition template assembly, this invention is more suitable for complex query scenarios with dynamic entities, dynamic fields, multi-level association navigation and nested exists / notexists; supports dynamic calculation fields of FORMULA type and parsing of virtualreciprocallinkfield that does not directly store association relationships, further expanding the semantic system of dot syntax.

[0015] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit the invention. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0017] Figure 1 This is a flowchart illustrating a query method using a structured query language according to an exemplary embodiment; Figure 2 This is an overall architecture diagram of a query method illustrated according to an exemplary embodiment; Figure 3 This is a flowchart illustrating the conversion of Groovy query syntax to SQL equivalent conditions according to an exemplary embodiment; Figure 4This is a flowchart illustrating dynamic attribute navigation and field type operator dispatch according to an exemplary embodiment; Figure 5 This is a flowchart illustrating the construction of nested subqueries '_exists / _notExists' according to an exemplary embodiment; Figure 6 This is a flowchart illustrating the unique object location and subsequent navigation for '_findOne' according to an exemplary embodiment. Figure 7 This is an architecture diagram of a query system using a structured query language, illustrated according to an exemplary embodiment. Figure 8 This is a schematic diagram of the structure of a computer device according to an exemplary embodiment. Detailed Implementation

[0018] Figures 1-2 An embodiment of a query method using a structured query language according to the present invention is shown.

[0019] In this optional embodiment, the query method of the structured query language includes: S101. Receive the initial data object, and create and bind the root query object of the current project identifier through the script entry method.

[0020] Specifically, this invention defines an entry method '_' in the script class 'BaseDotWalkingScript'.

[0021] This method receives a starting data object and constructs a query object 'DefaultDotWalking' by combining it with the project identifier in the current thread or context. Its functions include: 1. Converting script calls into chainable query objects; 2. Unifying the reception of root entity data, reference data, or collection data; 3. Establishing a query context at the current project level.

[0022] S102. Initialize the entity context with the root query object as the current query object, load the entity field metadata corresponding to the target entity, and establish a field mapping from field type to field type operator.

[0023] In this optional embodiment, the entity context is initialized with the root query object as the current query object, and the entity field metadata corresponding to the target entity is loaded. Establishing the field mapping from field type to field type operator includes: Using the root query object as the current query object, set the corresponding entity context parameters and the current field reference relationship. The entity context parameters include 'projectToken' project identifier, 'pbcToken' business object identifier, and 'formEntityToken' entity identifier.

[0024] Determine whether the internal data of the currently queried object carries a unique identifier 'id'. If it does, query the entity details data and, based on whether the field that triggered the current navigation is a reference field, set the target entity corresponding to the next navigation scope, thus initializing the field metadata and field operators.

[0025] Based on the entity context parameters of the current navigation scope, the field service is invoked to query the list of field definitions under the target entity. If the list of field definitions is empty, a field metadata missing exception is thrown. Otherwise, the list of field definitions is converted into a field mapping with field terms as keys and field definition objects as values.

[0026] Specifically, 'DefaultDotWalking' inherits from 'AbstractDotWalking'. During its construction, it performs the following tasks: 1. Sets context parameters such as 'projectToken', 'pbcToken', and 'formEntityToken'; 2. Determines whether to query entity details data based on whether the current object carries an 'id'; 3. Determines the target entity for subsequent navigation based on whether the current field is a reference field; 4. Initializes field metadata and field operator mappings. This step ensures that each dot syntax navigation continues execution within a new entity context.

[0027] Furthermore, in 'AbstractDotWalking#initFields', all field definitions of the current navigation target entity are read through 'formEntityFieldService.listByFormEntityToken(pbcToken,formEntityToken,projectToken)'. The steps include at least: 1. Receiving 'pbcToken', 'formEntityToken', and 'projectToken' corresponding to the current navigation scope; 2. Calling the field service to query the field definition list corresponding to the target entity; 3. Throwing an exception when the field definition list is empty, indicating that the current entity lacks field metadata; 4. When the field definition list is not empty, converting the field definition list into a field mapping relationship of 'field token -> field definition object' and caching it in 'fields'. The technical benefit of this step is that it enables expressions such as 'it.title', 'it.userStoryEditable', and 'it.taskACL' in the script to no longer rely on compile-time static Java properties, but instead to complete field identification at runtime based on dynamic entity metadata, thereby adapting to dynamic entity and dynamic field scenarios in low-code platforms.

[0028] S103. In response to the script's access to the attribute of the current query object, the field type of the accessed attribute in the field mapping is distinguished through dynamic attribute interception. Based on the field type, the corresponding field type operator is called to perform parsing, either returning the field value or generating an associated lower-level query object.

[0029] In this optional embodiment, in response to the script's access to the attribute of the current query object, dynamic attribute interception is used to distinguish the field type of the accessed attribute in the field mapping. Based on the field type, the corresponding field type operator is invoked to perform parsing, returning the field value or generating an associated lower-level query object, including: When the script runs, it listens for attribute access events of the currently queried object, extracts the accessed attribute name, and searches for the corresponding field definition object in the current field mapping. If no field definition object is found, it determines that the attribute name belongs to a business field or a built-in field.

[0030] If the attribute name is neither a business field nor a built-in field, then there is no exception in the output field.

[0031] If the attribute name is a built-in field, the field value is read directly from the current data object, and an empty value is returned if the current data object is empty.

[0032] If the attribute name belongs to a business field, then the field type of that business field is read, and the corresponding field type operator is obtained based on the field type to perform field parsing and generate a new sub-query object.

[0033] Specifically, such as Figure 4 As shown, in 'AbstractDotWalking#propertyMissing', when a script expression accesses a property, the system executes the following processing flow: 1. Read the accessed property name 'token'; 2. Search for the field definition object corresponding to the property name in the current field mapping 'fields'; 3. If no field definition object is found, determine whether the property belongs to the built-in field collection; 4. If it belongs to neither a business field nor a built-in field, throw a field not found exception; 5. If it belongs to a built-in field, directly read the corresponding field value from the current data object, returning an empty value if the current data object is empty; 6. If it belongs to a business field, read the field type of the field; 7. Obtain the corresponding field type operator from the 'dotOperators' mapping based on the field type; 8. Call the 'parserValue(field,data,projectToken)' method of the field type operator to perform field parsing. Through the above mechanism, Groovy dot syntax in this invention no longer only represents object property values, but also simultaneously undertakes the composite semantics of field access, navigation of associated objects, and switching of sub-table data.

[0034] In this optional embodiment, if the attribute name belongs to a business field, the field type of the business field is read, and the corresponding field type operator is obtained based on the field type to perform field parsing and generate a new lower-level query object, including: If the field type is identified as a basic field, the corresponding field value is extracted from the data within the current query object and a scalar value is returned.

[0035] If the field type is identified as a single-value associated field, it is determined whether the associated value is empty. If it is empty, an empty query object is returned as the lower-level query object. If it is not empty, a query object containing a single associated data is constructed as the lower-level query object.

[0036] If the field type is identified as a multi-valued related field, then a query object containing multiple related data is constructed as a lower-level query object.

[0037] If the field type is identified as a sub-table field, the sub-table entity identifier and business object identifier are parsed according to the field configuration. The sub-table query service is called to obtain the sub-table data list. If the list is empty, an empty query object is returned as the lower-level query object. If the list is not empty, the list is wrapped into a query object as the lower-level query object.

[0038] If the field type identifies a dynamically calculated field, then the formula expression and dependent field values ​​are read, the expression calculator is invoked to perform dynamic calculations, and a scalar value is returned. Alternatively, in the filter expression, the comparison condition for the dynamically calculated field can be rewritten as a query condition for the dependent base field of the dynamically calculated field.

[0039] If the field type identifies a virtual backlink field, the referenced field and mapping field configuration are read, and the link values ​​in the data within the current query object are combined to construct the backlink payload and execute the peer entity query. If the query result is unique, a query object containing a single piece of data is constructed as the lower-level query object; if the query result has multiple results, a query object containing multiple pieces of data is constructed as the lower-level query object; if no results are found, an empty query object is returned as the lower-level query object.

[0040] This invention defines a field type-driven navigation transformation strategy through the 'DotOperator' interface. The field type operator takes a field definition object, the current data object, and an item identifier as input, and outputs a field value, a related query object, or an empty query object. It includes at least the following five types of implementation logic: 1. Basic Field Parsing Logic. For basic fields such as text, number, time, date, radio button, rating, and switch, the field type operator directly reads the field value from the current data object and uses the field value as the left or right value in subsequent comparison expressions to participate in the construction of filtering conditions.

[0041] 2. Related Field Parsing Logic. For related fields such as ACL, Select, and tree selection, the field type operator first checks if the current field value is empty; if empty, it returns 'NullDotWalking'; if not empty, it determines whether to return a single object query object or an object collection query object based on whether the field is a multi-valued field, in order to support continued execution of chained navigation of objects / related objects / subordinate related objects.

[0042] 3. Sub-table field parsing logic. For fields of type 'EDITABLE_GRID', the field type operator first parses out the sub-table entity identifier and business object identifier based on the field configuration, and then calls the sub-table query service to obtain the sub-table data list corresponding to the current main object; if the result is empty, an empty query object is returned; if the result is not empty, the result list is wrapped into a new query object to support further dot syntax access and filtering of the sub-table records.

[0043] 4. FORMULA Type Dynamic Calculation Field Parsing Logic. For FORMULA fields, the field type operator reads the 'expression', 'value', and 'errorMessage' from the formula object, constructs a calculation context based on the dependent field values ​​in the current data object, and calls 'ExpressionCalculator.calculate(...)' to obtain the calculation result; a scalar value is returned upon successful calculation, and a null value or error message is returned upon failure. In some implementations, when this dynamically calculated field appears in a filtering expression, the system can rewrite the comparison condition for the calculated field as a query condition for its dependent base fields, or perform secondary calculation filtering after obtaining the candidate dataset.

[0044] 5. Virtual Field Parsing Logic. For virtual reciprocal link fields that do not directly store the relationship in the current entity, the field type operator reads 'referenceField', 'mappingFields', and 'linkValue' from the current object, constructs a 'QueryPayload' with '@referenceField=linkValue' as the core condition, and performs a reverse lookup of the peer entity. If the query result is unique, a single-object query object is returned; if the query result is multiple, a collection query object is returned; if no result is found, 'NullDotWalking' is returned to support continued dot syntax navigation and '_exists / _notExists' filtering.

[0045] S104. When the lower-level query object calls the filtering method and passes in the closure, the closure source code is parsed into an abstract syntax tree. The abstract syntax tree is traversed to distinguish between field paths and runtime parameter values, generating linear intermediate calculation units. The intermediate calculation units are then reduced to form a structured filtering model.

[0046] In this optional embodiment, when the lower-level query object calls the filtering method and passes in a closure, the closure source code is parsed into an abstract syntax tree. The abstract syntax tree is traversed to distinguish between field paths and runtime parameter values, generating linear intermediate computation units. These intermediate computation units are then reduced to form a structured filtering model, including: When the current query object receives a filtering request or a unique object query request, it captures the closure object and closure source code string carried in the request, and calls the abstract syntax tree construction tool to parse the closure source code string into a complete abstract syntax tree structure.

[0047] By recursively traversing each node of the abstract syntax tree using a syntax accessor, the system distinguishes between the left-hand field path and the right-hand runtime parameter of the expression, completes parameter binding, parses the actual parameter value, and records the current column identifier.

[0048] In this optional embodiment, the abstract syntax tree is recursively traversed through each node by a syntax accessor to distinguish between the lvalue field path and the rvalue runtime parameter of the expression, complete the parameter binding and parse the actual parameter value, and record the current column identifier, including: When traversing a binary expression, obtain the position identifier of the right subexpression in the source code, which consists of the starting line number, starting column number, ending line number, and ending column number, and record this position identifier in the set of right value nodes.

[0049] When traversing to an attribute expression, a position identifier for that attribute expression is generated, and it is determined whether that position identifier exists in the set of right-value nodes.

[0050] If it exists, it is set as the rvalue parameter path. The corresponding source code segment is extracted from the closure source code, and after removing newline, tab, and whitespace characters, the actual parameter value is extracted in combination with the runtime binding parameters.

[0051] If it does not exist, it is set as the lvalue field path. The object expression and property name are recursively read and concatenated in order from parent to child to form the field path string. The field path is recorded as the current column identifier and is used as the parent path prefix for inheritance when it exists or does not exist during recursive parsing.

[0052] Based on parameter binding and the parsing results of actual parameter values, logical operators, comparison operators and special query keywords are identified, and linear intermediate calculation units are generated in the parsing order.

[0053] The logical expression is transformed using an infix-to-postfix algorithm, and then a stack-based reduction algorithm is used to transform the linear intermediate computational units into a tree-shaped structured filtering model.

[0054] In this optional embodiment, the logical expression is transformed using an infix-to-postfix algorithm, and then the linear intermediate computational units are converted into a tree-shaped structured filtering model using a stack-based reduction algorithm, including: The method of merging intermediate computation units is called to remove the outermost paired parentheses, traverse the list of linear intermediate computation units, identify consecutive column paths, operators, and filter value triples as a basic filter unit, and convert it into a filter model object by initializing the filter model.

[0055] Call the method to parse the list of postfix expressions, and use the operator stack to convert infix logical AND, logical OR, and bracket expressions into postfix expressions.

[0056] The calculation method is called to perform stack-based calculation on the postfix expression. When a basic filtering unit is encountered, it is pushed onto the stack. When a logical AND is encountered, the filtering results on both sides of the stack are merged into the same condition list. When a logical OR is encountered, a compound OR condition node is constructed to obtain a list of structured filtering models.

[0057] Specifically, when a query object calls '_filter' or '_findOne', the system begins AST parsing of the closure expression. Specifically: 1. '_filter' returns a list of results; 2. '_findOne' returns a unique result object; 3. '_resolve' normalizes the current query result into a list output. For '_filter', the system performs the following steps: 1. Constructs the AST from the closure source string using 'AstBuilder.buildFromString(...)'; 2. Creates 'DotSqlWhereVisitor'; 3. Accesses the AST root node; 4. Calls 'getWhere()' to obtain the structured filtering model; 5. Overlays the current scope ID set filtering conditions; 6. Calls the underlying data service to execute the query.

[0058] It should be noted that 'DotSqlWhereVisitor' is the key parser in this invention, used to convert the syntactic structure in Groovy closures into SQL equivalent filtering conditions. This includes the following aspects: 1. Comparison and Logical Expression Parsing: In 'visitBinaryExpression', the system recognizes the following operations: '==', '!=', '>', '>=', '<', '<=', '&&', '||', and converts them into internal filtering keywords: 'equals', 'notequal', 'greaterthan', 'greaterthanorequal', 'lessthan', 'lessthanorequal', 'and', 'or'.

[0059] 2. Distinguishing between Field Paths and Parameter Values: To distinguish whether an attribute expression is a field path or a runtime parameter path in a comparison expression, this invention employs a left-right value judgment algorithm based on AST node position identifiers. To avoid insufficient disclosure and to further clarify the specific judgment algorithm for the left and right value sides of the expression, this invention describes the judgment process as follows: Step 1: When the syntax accessor traverses the binary expression 'BinaryExpression', it first obtains the left and right sub-expressions of the binary expression; Step 2: A node position identifier is generated for the right sub-expression, which includes at least the starting row number, starting column number, ending row number, and ending column number; Step 3: The node position identifier of the right sub-expression is written into the right value node set 'rightExpress'; Step 4: When the syntax accessor continues to traverse a certain attribute expression 'PropertyExpression', it again judges the left and right values ​​based on the attribute expression... Step 5: Determine if the node position identifier of the attribute expression exists in the set of rvalue nodes; Step 6: If it exists, the attribute expression is considered an rvalue-based expression. The system extracts the source code segment corresponding to the attribute expression from the closure source code, removes newlines, tabs, and whitespace characters, and extracts the corresponding real parameter value in combination with runtime 'binding'; Step 7: If it does not exist, the attribute expression is considered an lvalue-based expression. The system recursively reads the object expression and attribute name of the attribute expression, and concatenates them in order from parent to child to obtain the field path string, such as 'epic.feature.name'; Step 8: When the attribute expression is identified as an lvalue-based expression, the system also records the current field path as 'currentColId' so that it can be inherited downwards as the parent path prefix during the recursive parsing of '_exists' or '_notExists'.

[0060] Through steps 1 to 8 above, the present invention can simultaneously support multiple expression forms such as 'it.name==“bot”’, 'it.name==userName’, and 'it.name==_system_.user.name’.

[0061] 3. Keyword Parsing: This invention supports the following query keywords: '_contains', '_notContains', '_in', '_between', '_startsWith', '_endsWith', '_blank', '_notBlank', '_exists', and '_notExists'. When accessing the parameter list, the system calls the corresponding parsing function based on the current keyword to convert it into intermediate filtering units.

[0062] 4. Nested exists / notexists recursive parsing: When '_exists' or '_notExists' is detected, the system extracts its closure source code, creates a new 'DotSqlWhereVisitor' recursively parses the inner expression, and passes the current column path as the parent path prefix. This mechanism enables the present invention to naturally support multi-level related subqueries.

[0063] Furthermore, during AST access, the system does not directly output the final SQL or the final filter tree. Instead, it first generates linear intermediate calculation units 'calculateCells'. These intermediate calculation units include at least the following types: 1. 'FILTER', used to represent field paths, operators, or parameter values; 2. 'AND', used to represent logical AND; 3. 'OR', used to represent logical OR; 4. 'LEFT_BRACKET', used to indicate the start of a left bracket group; 5. 'RIGHT_BRACKET', used to indicate the end of a right bracket group.

[0064] After obtaining intermediate calculation units, the system performs the following reduction steps: 1. Basic filter unit merging step. The system calls 'mergeCalculateCells()' to identify consecutive column name, operator, and value triples as a basic filter unit, and converts it to 'FilterModel' through 'initFilterModel(...)'. 2. Infix to postfix conversion step. The system calls 'parseSuffixExpressionList(...)' to convert the infix logical expression composed of 'AND', 'OR', and parentheses into a postfix expression based on the operator stack and output sequence. 3. Stack-based reduction step. The system call 'calculate(...)' performs stack-based computation on the postfix expressions: when a basic filtering unit is encountered, it is pushed onto the computation stack; when 'AND' is encountered, the filtering results on both sides are merged into the same condition list; when 'OR' is encountered, the filtering results on both sides are merged into a composite filtering node with 'operator="or"'; when a filtering unit corresponding to 'EXISTS' or 'NOT_EXISTS' is encountered, its internal recursive filtering results are added as sub-conditions to the current filtering model. 4. Output the structured filtering model steps. After all postfix expressions have been reduced, the result at the top of the stack is the final list of structured filtering models. The list of filtering models can be directly written into the query payload and handed over to the backend query engine for further compilation and execution.

[0065] S105. Extract the identifier set of each object in the data object set of the lower-level query object, construct the scope filtering conditions, and combine the structured filtering model with the scope filtering conditions into the query payload.

[0066] In this optional embodiment, the identifier set of each object within the data object set in the lower-level query object is extracted, scope filtering conditions are constructed, and the structured filtering model and scope filtering conditions are combined into a query payload, including: Determine whether the data inside the currently queried object is a single object or a collection of objects.

[0067] If it is a collection of objects, then iterate through the current collection of objects to extract the identifiers of all objects, forming a scope identifier set. If it is a single object, then directly extract the identifier of that object to construct a single-element scope identifier set.

[0068] Based on the scope identifier set, construct a scope filter condition with the field being identifier, the filter type being set matching, and the value being the scope identifier set.

[0069] The structured filtering model and scope filtering conditions are written together into the query payload.

[0070] Specifically, to ensure that the query scope after dot syntax navigation is always limited to the current navigation object set, this invention adds scope filtering conditions to '_filter' in addition to the filtering model generated by the user expression. The steps include at least: 1. Determining whether the data inside the current query object is a single object or a collection of objects; 2. If it is a collection of objects, traversing the current object collection and extracting all object IDs to form a scope ID set; 3. If it is a single object, directly extracting the current object ID and constructing a single-element scope ID set; 4. Constructing a filtering model of type 'idin(...)' based on the scope ID set; 5. Writing the scope filtering model and the filtering model generated by the user expression together into 'QueryPayload'. The technical function of this step is to transform the semantics of dot syntax navigation to a certain level of object collection into the database query semantics of continuing to execute condition filtering within the data range limited by that object collection, thereby avoiding cross-level error amplification of the query scope.

[0071] In '_findOne', the system executes the following processing logic: 1. Receive the query closure and its source code string as input; 2. First, call '_filter' to perform filtering within the current navigation scope, obtaining a list of results; 3. When the number of results in the list is greater than 1, throw a unique object location exception, indicating that the current query result is not unique; 4. When the number of results in the list is equal to 1, wrap the unique result into a new 'DefaultDotWalking' query object to support continued navigation to lower-level associated objects; 5. When the result list is empty, return an empty query object 'NullDotWalking'. The purpose of 'NullDotWalking' is to prevent script execution from immediately causing an exception when a certain level of navigation result is empty, instead continuing to pass it in the form of an empty query object. For empty query objects, '_filter' returns an empty list, '_findOne' returns a new empty query object, and '_resolve' returns an empty result list.

[0072] S106. Compile the query payload to generate an executable structured query language statement and execute it to obtain the query results.

[0073] In this optional embodiment, the query payload is compiled to generate an executable structured query language statement and executed to obtain query results including: The query payload is serialized into a string and then the data service entry method is called, passing in the serialized query payload.

[0074] In the backend service, the query payload is deserialized, and the business field token or dot syntax field path in the query payload is replaced with the actual stored field. The association query tree is constructed according to the association level in the field path, and join clauses, subqueries, or exist / not exist query fragments are generated.

[0075] The structured filtering model is recursively compiled to generate conditional clause fragments and corresponding pre-compiled parameter lists. The main table, join, condition, sort, pagination, logical deletion filtering, and data permission filtering are then merged to obtain the final executable structured query language statement.

[0076] Executes a Structured Query Language statement and returns a list of query results.

[0077] S107. Based on the query result type, encapsulate the query result into a new query object that supports continued navigation, or convert it into a standardized result list and return it.

[0078] In this optional embodiment, depending on the query result type, the query results are either encapsulated into a new query object that supports continued navigation, or converted into a standardized result list and returned, including: Identify the current request type as a list query request, a unique object query request, or a standardized output request.

[0079] If it is a unique object query request, it is encapsulated into the corresponding root query object or subordinate query object according to the number of results, and a uniqueness exception check is performed.

[0080] If it is a list query request, the result set is encapsulated into a group of query objects that can be chained.

[0081] If it is a standardized output request, the internal results will be uniformly converted into a standard list structure.

[0082] The encapsulated and processed result is sent back to the script caller.

[0083] Specifically, such as Figure 6As shown, this invention also includes the following exception types and handling mechanisms: 1. Field Not Found Exception. Triggering condition: The attribute accessed by the script does not belong to the current entity field mapping or the built-in field set; Handling method: Immediately throw a field not found exception to prevent subsequent error navigation. 2. Field Metadata Missing Exception. Triggering condition: No field definition can be found based on 'pbcToken', 'formEntityToken', and 'projectToken'; Handling method: Throw a metadata missing exception, indicating that the current entity cannot complete dot syntax field recognition. 3. Operator Not Supported Exception. Triggering condition: The AST accessor recognizes an unsupported comparison operator or keyword; Handling method: Throw an unsupported exception to prevent the generation of an error filtering model. 4. Parameter Quantity Illegal Exception. Triggering condition: The number of parameters passed to '_in' does not meet the requirements, or '_between' does not pass two boundary values, or the number of parameters passed to keyword methods such as '_contains', '_startsWith', and '_endsWith' is incorrect; Handling method: Throw an illegal parameter quantity exception. 5. Unique Object Locator Exception. Triggering condition: '_findOne' finds multiple records within the current scope; Handling method: Throws a unique object location exception, indicating that the result is not unique. 6. Null navigation result handling mechanism. Triggering condition: The associated field is null, the sub-table result is null, or '_findOne' does not find a result; Handling method: Returns 'NullDotWalking', and subsequent '_filter' and '_resolve' output null results instead of throwing a null pointer exception.

[0084] To further demonstrate the complete technical loop of this invention from Groovy query expressions to SQL query execution, after generating the structured filtering model, this invention also includes the following backend compilation and execution steps: 1. In '_filter' or '_findOne', the structured filtering model and the scope ID filtering condition are written together into 'QueryPayload'; 2. 'QueryPayload' is serialized into a string and the data service entry method 'internalSdkList(...)' is called; 3. In the backend service, the string 'QueryPayload' is deserialized into a query payload object; 4. Call... The underlying data warehouse layer's query method further compiles the query payload into executable SQL; 5. During compilation, the business field token or dot-walking field path is replaced with the actual stored field; 6. A relational query tree is constructed based on the relational hierarchy in the field path to generate JOIN, subqueries, or EXISTS / NOTEXISTS query fragments; 7. Recursive compilation is performed on the structured filtering model to generate WHERE condition fragments and corresponding pre-compiled parameter lists; 8. The main table, JOIN, WHERE, sorting, pagination, logical deletion filtering, and data permission filtering are merged to obtain the final executable SQL; 9. The SQL is executed and a result list is returned. Through the above steps, this invention does not achieve simple string replacement-based SQL generation, but rather a layered compilation and execution mechanism: Groovy query expression -> AST semantic parsing -> structured QueryPayload -> relational query tree compilation -> pre-compiled SQL execution.

[0085] This invention further clarifies the key method definitions, input structures, core processing logic, and output structures in the query chain, including at least the following methods: 1. The 'getWhere()' method. Input: A 'Binding' object, the closure source code string 'sourceCode', the parent path 'parentColId', and a list of intermediate access cells 'calculateCells'. Core processing logic: First, 'mergeCalculateCells()' is called to merge linear cells into a list 'CalculateQuery', then 'parseSuffixExpressionList(...)' is called to generate postfix expressions, and finally 'calculate(...)' is called to obtain the structured filtering model. Output: 'List' <filtermodel>A list of filter models in 'format', with the output directed to either the '_filter' or '_findOne' method.

[0086] 2. The `_filter(Closureclosure, String closureStr)` method. Inputs: the closure object `'closure'`, the closure source code in string form `'closureStr'`, runtime `binding' parameter mapping, and data within the current navigation scope. Core processing logic: Construct the AST using `AstBuilder.buildFromString(closureStr)`, create `DotSqlWhereVisitor` to traverse the AST, and obtain a `List` using `getWhere()`. <filtermodel>Then, create a 'QueryPayload', write the user filtering model and the scope conditions generated by 'idFilter(filterIds())' together, and then serialize the 'QueryPayload' using 'GsonUtils.toJson(...)' before calling 'internalSdkList(...)' to execute the query. Output: If 'PageResult' is not empty, return the 'List' corresponding to 'pageResult.getResults()'. <map>'Or a list of results; if empty, it returns 'Collections.emptyList()'.

[0087] 3. The `_findOne(Closureclosure, String closureStr)` method. Input: Closure objects 'closure' and 'closureStr'. Core processing logic: First, call `_filter(...)` to obtain the list of results in the current scope; if the list contains more than one result, throw a uniqueness exception; if the list contains one result, wrap the unique result into a new 'DefaultDotWalking'; if no result is found, return 'NullDotWalking'. Output: 'DefaultDotWalking' object, 'NullDotWalking' object, or a uniqueness exception.

[0088] 4. The '_resolve()' method. Input: The data 'data' inside the current query object, where 'data' can be a single 'Map' object or a 'List'. <map>'Set or null value. Core processing logic: When 'data' is a set, return the set directly; when 'data' is a single object, convert it to a single-element list; when 'data' is empty, return null value or an empty list. Output: A standardized 'List' structure for direct use by the script side.'

[0089] 5. The 'mergeCalculateCells()' method. Input: 'List <calculatevisit>A list of linear intermediate access cells named 'calculateCells' in the format 'FILTER', 'AND', 'OR', 'LEFT_BRACKET', and 'RIGHT_BRACKET'. Core processing logic: Remove the outermost paired parentheses and iterate through 'calculateCells' sequentially. When a column path, operator, and filter value triple is identified, 'initFilterModel(...)' is called to generate the corresponding 'FilterModel', which is then encapsulated as a 'CalculateQuery' cell. Output: 'List' <calculatequery>A list of basic filter units in 'format', with output directed to 'parseSuffixExpressionList(...)'.

[0090] 6.'parseSuffixExpressionList(List <calculatequery>The `calculateQueries)` method. Input: `List<Queries>` <calculatequery>A list of infix logical expression units in the format '. Core processing logic: Use operator stack s1 and output sequence s2 to process 'FILTER', 'AND', 'OR', 'LEFT_BRACKET', and 'RIGHT_BRACKET', converting the infix expressions to postfix expressions according to precedence and bracket grouping relationships. Output: 'List <calculatequery>A list of postfix expressions in the format 'calculate(...)', the output destination is 'calculate(...)'.

[0091] 7. 'calculate(List <calculatequery>The `ls` method. Input: 'List' <calculatequery>A list of postfix expressions in 'format'. Core processing logic: Use a stack structure to sequentially read postfix units; when encountering 'FILTER', push 'FilterModel' onto the stack; when encountering 'AND', merge the filtering results on both sides of the stack into the same condition list; when encountering 'OR', construct a compound filter node with operator="or". Output: 'List <filtermodel>A list of structured filtering models in 'format'.

[0092] 8.'filterIds()' and 'idFilter(Set <string>The `filterIds()` method takes two inputs: 'data' (the data within the current navigation scope) or 'ids' (a collection of object IDs). The core processing logic is: when 'data' is a 'List', `filterIds()` extracts all 'id' values ​​and converts them to a 'Set'. <string>When 'data' is a single object, a single-element ID set is constructed; 'idFilter(...)' constructs a 'FilterModel' with colId="id", filterType="set", and 'values=ids' based on ids. Output: The scope ID set and its corresponding ID filtering model, the output destination is the 'QueryPayload' assembly process in '_filter(...)'.

[0093] Figure 7 An embodiment of a query system based on a structured query language according to the present invention is shown.

[0094] In this optional embodiment, the query system of the Structured Query Language includes: The query entry construction module 201 is used to receive the initial data object and create and bind the root query object of the current project identifier through the script entry method.

[0095] The initialization loading module 202 is used to initialize the entity context with the root query object as the current query object, load the entity field metadata corresponding to the target entity, and establish the field mapping from field type to field type operator.

[0096] The dot syntax navigation module 203 is used to respond to script accesses to attributes of the current query object. It distinguishes the field type of the accessed attribute in the field mapping through dynamic attribute interception. Based on the field type, it calls the corresponding field type operator to perform parsing, either returning the field value or generating the associated sub-query object.

[0097] The filter model generation module 204 is used to parse the closure source code into an abstract syntax tree when the lower-level query object calls the filter method and passes in the closure. It traverses the abstract syntax tree to distinguish field paths and runtime parameter values, generates linear intermediate calculation units, and reduces the intermediate calculation units to form a structured filter model.

[0098] The query payload construction module 205 is used to extract the identifier set of each object in the data object set of the lower-level query object, construct the scope filtering conditions, and combine the structured filtering model with the scope filtering conditions into the query payload.

[0099] The backend compilation and execution module 206 is used to compile the query payload, generate an executable structured query language statement, and execute it to obtain the query results.

[0100] The result feedback parsing module 207 is used to encapsulate the query results into a new query object that supports continued navigation, or to convert it into a standardized result list and return it, depending on the query result type.

[0101] To facilitate understanding of the above technical solutions of the present invention, the following further explains the above technical solutions of the present invention from the perspective of architecture and principle.

[0102] The technical problem this invention aims to solve is to provide a structured query language query method suitable for dynamic entities and dynamic fields. This method enables users to directly describe multi-level association query conditions, unique object location conditions, and nested exists / notexists conditions based on dynamic field metadata using Groovy dot syntax and closure expressions. At runtime, through dynamic attribute interception, field type assignment, AST semantic parsing, and scope constraints, the syntax expression is converted into a structured query payload and SQL equivalent query conditions. This improves the expressiveness, execution accuracy, and maintainability of dynamic business object queries in complex association scenarios.

[0103] This invention provides an SQL query method based on Groovy query expression parsing.

[0104] This method receives the initial data object and creates a query object through the script entry method; When a query object is initialized, it loads the entity field metadata under the current navigation scope based on the current project identifier, business object identifier, and entity identifier, and establishes a mapping relationship between field types and field type operators.

[0105] When a user accesses an attribute in a script using Groovy dot syntax, the system uses a dynamic attribute interception mechanism to identify whether the accessed attribute belongs to a built-in field or a business field. When the accessed attribute belongs to a business field, the system dispatches it to the corresponding field type operator for parsing based on the field type. For basic fields, the field type operator returns the field value; for related fields, multi-value related fields, or sub-table fields, the field type operator returns a new query object, enabling the script to continue executing cross-entity chain navigation.

[0106] In some implementations, the field type operator also supports dynamically computed fields of FORMULA type and virtual reciprocallink fields that do not directly store associations, in order to extend the semantic system of dot syntax.

[0107] When a user calls the '_filter' or '_findOne' method, the system constructs a Groovy Abstract Syntax Tree (AST) from the closure source code string and recursively accesses comparison expressions, logical expressions, keyword method expressions, and nested closure expressions through syntax accessors to generate linear intermediate computation units. Subsequently, the system merges the intermediate computation units into basic filtering units and then forms a tree-structured filtering model through infix to postfix conversion and stack-based reduction.

[0108] After obtaining the structured filtering model, the system further extracts a set of scope IDs based on the data object set within the current navigation scope. This set of scope IDs is then written into the query payload (QueryPayload) as additional filtering conditions to ensure that the query is executed only within the data scope corresponding to the current dot syntax navigation. Next, the system calls the underlying data service, replaces the token path field with the actual stored field, constructs a relational query tree, compiles the structured filtering model into a pre-compiled SQL statement and parameter list, executes the query, and finally returns a result list, unique object query results, or standardized parsed results.

[0109] Unlike solutions based on SQL template configuration or string concatenation, this invention does not directly generate SQL by replacing a preset template. Instead, it achieves automatic conversion from native Groovy query expressions to equivalent SQL query conditions through a complete technology chain including dynamic field metadata loading, dot syntax navigation, AST semantic parsing, scope constraints, structured filtering model construction, and backend compilation and execution.

[0110] To further clarify the component boundaries, input / output parameters, core processing logic, and interaction timing between components in this invention, the core components of the system are defined as follows. These components can be deployed within the same server process or distributed according to a service model, but their functional division and calling relationships remain unchanged.

[0111] 1. DSL Query Entry Point Construction Component. Functional Boundaries: Responsible for receiving raw query entry requests initiated by the script side and creating the root query object; not responsible for field parsing or SQL compilation. Input Parameters: 'data', in the format of a single business object, a list of business objects, or a collection of navigable objects, originating from the script execution context; 'projectToken', in the format of a string identifier, originating from the thread context or script context. Core Processing Logic: Calls the entry method '_', converting the script call into the 'DefaultDotWalking' root query object and binding it to the current project identifier. Output Parameters: Root query object 'rootWalker'. Output Destination: Sent to the query context initialization component. Interaction Sequence: This component executes first among all components.

[0112] 2. Query Context Initialization Component. Functional Boundaries: Responsible for establishing the entity context corresponding to the current navigation level; not responsible for closure parsing or backend execution. Input Parameters: 'data' (internal data of the current query object); 'currentField' (current field definition, formatted as a field definition object); 'projectToken' (project identifier). Source: From the previous level query object or entry point building component. Core Processing Logic: Determines the 'pbcToken', 'formEntityToken', and 'projectToken' corresponding to the current navigation target, as well as the current field reference relationship, and determines the subsequent scope based on whether the current data is a single object or a collection of objects. Output Parameters: 'walkerContext' (query object with context information). Output Destination: Sent to the entity field metadata loading component and the field type manipulator component. Interaction Sequence: Executed once each time the dot syntax is used to enter a new level.

[0113] 3. Entity Field Metadata Loading Component. Functional Boundaries: Responsible for reading the dynamic field definitions of the current entity and building a field index; not responsible for accessing and evaluating specific fields. Input Parameters: 'pbcToken', 'formEntityToken', and 'projectToken' are all string identifiers derived from the query context initialization component. Core Processing Logic: Calls the field service to read all field definitions of the current entity and constructs a 'Map'.<String,FieldDefinition> 'Field mapping in 'format'. Output parameter: Field mapping 'fields'. Output destination: Sent to the dynamic attribute interception and field dispatch component. Interaction sequence: Executed after the current entity context is established, and reused within the same context.

[0114] 4. Dynamic Property Interception and Field Dispatch Component. Functional Boundaries: Responsible for intercepting Groovy property access requests and determining whether the request should be processed as a built-in field or a business field. Input Parameters: Property name 'token', in string format; field mapping 'fields'; current data object 'data'. Source: From the 'propertyMissing' call during script runtime. Core Processing Logic: First, determine if 'token' matches the business field mapping; if not, determine if it belongs to a built-in field; if it matches a business field, transfer the field definition to the field type operator component. Output Parameters: Built-in field value, business field value, empty query object, or a new lower-level query object. Output Destination: Returned to the script caller, or passed to the downstream query context initialization component. Interaction Timing: Triggered in real time with each script property access.

[0115] 5. Field Type Manipulator Component. Functional Boundaries: Responsible for determining attribute access semantics based on field type; not responsible for Boolean expression reduction or SQL concatenation. Input Parameters: Field definition object 'fieldDefinition'; current data object 'data'; project identifier 'projectToken'.

[0116] Source: From the Dynamic Attribute Interception and Field Dispatch Component. Core Processing Logic: If the field is a base field, the value is directly retrieved and a scalar is returned; if the field is a single-value related field, a single-object query object is constructed; if the field is a multi-value related field, a collection query object is constructed; if the field is a sub-table field, the sub-table data is queried according to the sub-table configuration and a query object is constructed.

[0117] In some implementations, if the field is a FORMULA type dynamically calculated field, the 'expression', 'value', and 'errorMessage' in the formula object are read, the calculation is performed based on the current object context, and a scalar value is returned. If the field is a virtualreciprocallinkfield that does not directly store associations, a reverse query payload is constructed based on the 'referenceField', 'mappingFields', and the current object association value, and a single-object query object, a collection query object, or a 'NullDotWalking' object is returned.

[0118] Output parameters: scalar value, 'DefaultDotWalking' object, or 'NullDotWalking' object. Output destination: Returned to the script caller, or further delegated to the query context initialization component to complete the next level navigation. Interaction timing: Executed immediately after dynamic property interception.

[0119] 6. GroovyAST parsing component. Functional boundaries: Responsible for parsing the native Groovy closure received by '_filter' or '_findOne' into an abstract syntax tree; not responsible for loading field metadata. Input parameters: Closure object 'closure'; closure source code string 'closureSource'; runtime binding parameter 'binding', in the format 'Map'.<String,Object> Source: Filtering method call from the query object. Core processing logic: Call 'AstBuilder.buildFromString(...)' to build the AST, traversing comparison expressions, logical expressions, property expressions, variable expressions, and method call expressions to generate linear intermediate calculation units 'calculateCells'. Output parameter: List of intermediate calculation units 'calculateCells'. Output destination: Sent to the left / right value recognition and parameter binding component, and the Boolean expression reduction component. Interaction timing: Triggered when '_filter' or '_findOne' is called.

[0120] 7. Left / Right Value Recognition and Parameter Binding Component. Functional Boundaries: Responsible for distinguishing between field paths and runtime parameter paths within closures; not responsible for final SQL generation. Input Parameters: AST node position information, closure source code string 'closureSource', binding parameter 'binding'. Source: From the GroovyAST parsing component. Core Processing Logic: Records the set of right-value nodes when traversing binary expressions; when traversing attribute expressions, determines whether the current expression is a left-value or right-value based on the node position; recursively concatenates left-values ​​into field path strings, and parses right-values ​​into actual parameter values ​​based on source code snippets and 'binding'. Output Parameters: Field path string, runtime parameter value, current column identifier 'currentColId'. Output Destination: Sent to the Boolean expression reduction component and the '_exists / _notExists' recursive parsing process, such as... Figure 5 As shown. Interaction timing: Executed synchronously with AST traversal.

[0121] 8. Boolean Expression Reduction Component. Functional Boundaries: Responsible for reducing linear intermediate calculation units to structured filtering models; not responsible for backend service calls. Input Parameters: 'calculateCells', formatted as a list of intermediate calculation units. Source: From the GroovyAST parsing component and the left / right value recognition and parameter binding component. Core Processing Logic: First, 'mergeCalculateCells()' merges field paths, operators, and parameter values ​​into basic filtering units; then, 'parseSuffixExpressionList(...)' converts infix logical expressions to postfix expressions; finally, 'calculate(...)' reduces them to a tree-like 'FilterModel'. Output Parameters: Structured filtering models 'filterModels'. Output Destination: Sent to the scope constraint and query payload construction component. Interaction Timing: Executed after AST traversal.

[0122] 9. Scope Constraints and Query Payload Construction Component. Functional Boundaries: Responsible for transforming the scope of the current navigation object into query scope constraints and assembling a unified query payload; not responsible for underlying database compilation. Input Parameters: Structured filter model 'filterModels'; current navigation object or object collection; current object ID collection. Source: From the Boolean expression reduction component and the internal state of the current query object. Core Processing Logic: Extract the object ID corresponding to the current navigation level, construct scope filter conditions of type 'idin(...)', and write them together with the filter model generated by the user expression into 'QueryPayload'. The 'QueryPayload' is in the format of a structured query payload object, which can be serialized to JSON or a string. Output Parameters: Query payload 'QueryPayload'. Output Destination: Sent to the backend compilation and execution component. Interaction Timing: Executed after the filter model is formed.

[0123] 10. Backend Compilation and Execution Component. Functional Boundaries: Responsible for compiling 'QueryPayload' into executable SQL and calling the underlying data service for execution; not responsible for frontend script syntax parsing. Input Parameters: 'QueryPayload'; entity definition; project identifier; field mapping relationships. Source: From the scope restriction and query payload construction component. Core Processing Logic: Performs deserialization and field path parsing on 'QueryPayload', replaces the business field token or dot-walking field path with the actual stored field, constructs the join query tree, generates JOIN, EXISTS / NOTEXISTS, WHERE conditions and a pre-compiled parameter list, and then executes the SQL. Output Parameters: Result list, unique result or empty result. Output Destination: Sent to the query result navigation and result parsing component. Interaction Sequence: Executed after the query payload is assembled.

[0124] 11. Query Result Continuation Navigation and Result Parsing Component. Functional Boundaries: Responsible for receiving results returned from the backend, supporting continued dot syntax navigation, and returning unified results to the script; not responsible for constructing preceding filter conditions. Input Parameters: Result object or result list. Source: From the backend compilation and execution component. Core Processing Logic: For '_findOne', when the result is unique, the result is encapsulated into a new 'DefaultDotWalking' object; when the result is empty, a 'NullDotWalking' object is returned; when there are more than one result, a uniqueness exception is thrown. For '_resolve', the internal results are uniformly converted into a list structure for output. Output Parameters: New query object, empty query object, or standardized list results. Output Destination: Returned to the script caller, or re-entered into the dynamic attribute interception and field dispatch component. Interaction Sequence: Located at the end of the entire query chain, and can re-enter the next round of navigation.

[0125] like Figure 3 As shown, the overall interaction sequence of the above components is as follows: S1, the DSL query entry construction component receives the original object and creates the root query object; S2. The query context initialization component and the entity field metadata loading component complete the preparation of the current entity context and field mapping; S3, the dynamic attribute interception and field dispatch component and the field type manipulator component complete the dot syntax navigation; S4. When calling '_filter' or '_findOne', the GroovyAST parsing component, the left and right value recognition and parameter binding component, and the Boolean expression reduction component generate a structured filtering model in sequence. S5. The scope restriction and query payload construction component further superimposes the current navigation range constraints and forms 'QueryPayload'; S6. The backend compilation and execution component compiles it into SQL and returns the result; S7. The query results navigation and result parsing component will return the results to the script side or proceed to the next level of navigation.

[0126] The present invention will be further described below with reference to specific embodiments.

[0127] Example 1: Filtering of Multivalued Association Sets Example statement: "_("tableName").featureMultiACL._filter({it.title!="Dot"})".

[0128] The implementation process is as follows: 1. Call the '_' method to construct the root-level query object from the root object data.

[0129] 2. When accessing 'featureMultiACL', the dynamic attribute interception component identifies it as a business field and assigns it to the associated field operator based on the field type.

[0130] 3. Because this field is a multi-valued associated field, the field type operator returns a collection query object 'DefaultDotWalking'.

[0131] 4. After calling '_filter', the system will construct the closure '{it.title!="Dot"}' into an AST.

[0132] 5. The AST accessor recognizes 'title' as an lvalue field path, '!=' as an inequality comparison operation, and '"Dot"' as a constant rvalue.

[0133] 6. The system generates the basic filtering unit 'titleNOTEQUALDot' and further reduces it to a structured filtering model.

[0134] 7. The system extracts all object IDs from the current object set corresponding to 'featureMultiACL' and constructs the scope filtering conditions for 'idin(...)'.

[0135] 8. The system writes both user filtering conditions and scope filtering conditions into 'QueryPayload', calls the underlying data service to execute the query, and returns a list of results.

[0136] Example 2: Multi-level reference navigation result parsing Example statement: "_("tableName").featureACL.userStoryACL.taskACL._resolve()".

[0137] The implementation process is as follows: 1. When the root query object accesses 'featureACL', the field type operator resolves the first-level associated fields into a new query object. 2. When accessing 'userStoryACL' on the first-level query object, the system repeatedly performs field identification and associated object switching, switching the current navigation scope to the second-level associated entity. 3. When accessing 'taskACL' on the second-level query object, the system switches back to the third-level associated entity. 4. When '_resolve()' is called, the system determines the current internal data type; if it is a collection of objects, it directly returns the collection; if it is a single object, it converts it into a single-element list.

[0138] Example 3: Navigation continues after unique object location Example statement: "_("tableName").featureMultiACL._findOne({it.title=="DotWalking"}).userStoryACL.taskMultiACL._resolve()".

[0139] The implementation process is as follows: 1. The system first accesses 'featureMultiACL' to obtain the set of related objects constrained by the current root object. 2. When '_findOne' is called, the system first reuses the AST parsing and filtering model construction logic of '_filter', and executes the filtering of 'title=="DotWalking"' within the current scope. 3. If the result is empty, 'NullDotWalking' is returned; if the result is unique, the unique object is wrapped into a new query object; if there are more than one result, a unique object location exception is thrown. 4. If the result is unique, the system continues to access 'userStoryACL' and 'taskMultiACL', switching the navigation context level by level. 5. Finally, the final task set is output through '_resolve'.

[0140] Example 4: Combined query of exists / notexists Example statement: "_("tableName").featureMultiACL._filter{it.userStoryEditable._exists{it.title!="123"}||it.userStoryEditable._notExists{it.title!="123"}}".

[0141] The implementation process is as follows: 1. The current query object is first switched to the entity corresponding to 'featureMultiACL'. 2. When the AST accessor traverses '_exists', it records the current field path 'userStoryEditable' as the parent path prefix. 3. The system extracts the closure source code of '_exists' and creates a new syntax accessor to recursively parse 'it.title!="123"'. 4. During the recursive parsing process, the internal field path 'title' is concatenated with the parent path prefix to form 'userStoryEditable.title'. 5. The system packages this internal filtering result into an EXISTS filter unit. 6. The system performs the same recursive parsing process on '_notExists' to generate a NOTEXISTS filter unit. 7. The two filter units are combined using OR and then combined with the current scope ID set constraint to form the final query condition.

[0142] Example 5: Query with runtime parameters Example statement: "{it.epic._exists({it.name==epicName&&it.feature._exists{it.name==featureName}})}".

[0143] Where 'epicName' and 'featureName' are obtained from script runtime binding parameters.

[0144] The implementation process is as follows: 1. When the AST accessor traverses the comparison expression, it first records the position identifier of the rvalue node. 2. When accessing the property expression or variable expression corresponding to 'epicName' or 'featureName', the system determines that it belongs to the rvalue side expression based on the node position. 3. The system extracts the rvalue expression text from the closure source code and extracts the actual parameter value by combining 'binding' and 'ObjUtils.getProperty(...)'. 4. For the lvalue side expression 'it.name', the system recursively concatenates to obtain the field path 'name'; in the inner '_exists', it concatenates to obtain 'feature.name'. 5. The system constructs nested EXISTS filtering conditions of 'epic.name=epicName' and 'epic.feature.name=featureName'.

[0145] Example 6: Reduction of Logical Expressions Grouped in Parentheses Example statement: "_("tableName").featureMultiACL._filter{(it.title=="A"||it.title=="B")&&it.status!="C"}".

[0146] The implementation process is as follows: 1. The AST accessor splits comparison expressions and logical expressions into linear intermediate computation units, which include at least 'FILTER', 'OR', 'AND', 'LEFT_BRACKET', and 'RIGHT_BRACKET'. 2. The system merges 'title=="A"', 'title=="B"', and 'status!="C"' into basic filtering units using 'mergeCalculateCells()'. 3. The system converts infix logical expressions containing bracket groups into postfix expressions using 'parseSuffixExpressionList(...)'. 4. The system uses 'calculate(...)' to first reduce the two basic filtering units within the brackets to an OR composite node, and then performs an AND combination between this OR composite node and the basic filtering unit corresponding to 'status!="C"'. 5. The system finally obtains a tree-shaped filtering model consistent with the bracket structure of the original closure expression, and continues to add scope constraints to execute queries.

[0147] Example 7: Compiling and executing QueryPayload to SQL Example statement: "_("tableName").featureMultiACL._filter{it.title._contains("Dot")&&it.status=="OPEN"}".

[0148] The implementation process is as follows: 1. The system converts '_contains("Dot")' and '=="OPEN"' into a structured filtering model using an AST accessor. 2. The system extracts the set of object IDs from the current navigation scope and constructs additional scope filtering conditions. 3. The system writes the structured filtering model and scope filtering conditions together into 'QueryPayload', and serializes 'QueryPayload' before sending it to 'internalSdkList(...)'. 4. The backend service deserializes 'QueryPayload' and calls the data warehouse layer's query method. 5. The data warehouse layer replaces business fields such as 'title' and 'status' with actual stored fields and constructs a relational query tree based on the dot-walking path. 6. The system recursively compiles the filtering model, generating WHERE conditions, JOIN conditions, and a pre-compiled parameter list. 7. The system combines the main table, JOIN, WHERE, sorting, pagination, data permissions, and logical deletion filters to obtain the final executable SQL and returns the query results.

[0149] Example 8: Extended Navigation for Dynamically Calculated Fields and Virtual Fields Example statement: "_("tableName").featureMultiACL._filter{it.scoreFormula>80&&it.virtualStory._exists{it.status=="OPEN"}}".

[0150] The implementation process is as follows: 1. When the current query object accesses 'scoreFormula', the dynamic attribute interception component identifies it as a business field and dispatches it to the FORMULA field operator based on the field type. 2. The FORMULA field operator reads 'expression', 'value', and 'errorMessage' from the formula definition, extracts the formula dependency field values ​​from the current 'feature' object, constructs the calculation context, and calls 'ExpressionCalculator.calculate(...)' to obtain the calculation result. 3. The AST accessor parses 'it.scoreFormula>80' as a comparison condition for a dynamically calculated field; in some implementations, the comparison condition can be rewritten as a query condition for a dependent base field, or a secondary calculation filter can be performed after obtaining the candidate result set. 4. When 'virtualStory' is accessed, the field type operator identifies it as a virtual field that does not directly store associations and reads 'referenceField', 'mappingFields', and the association value 'linkValue' in the current object. 5. The system constructs a 'QueryPayload' with '@referenceField=linkValue' as the core condition, performing a reverse query on the peer entity corresponding to the virtual field. If a result is found, a single-object query object is returned; if multiple results are found, a collection query object is returned; if no result is found, 'NullDotWalking' is returned. 6. When calling '_exists' on the returned virtual field query object, the system inherits the parent path prefix and recursively parses '{it.status=="OPEN"}' to generate EXISTS filtering units for the virtual association scenario. 7. The system writes the dynamically calculated field comparison conditions, the virtual field EXISTS filtering conditions, and the current scope ID set constraints into the 'QueryPayload', which is then compiled and executed by the backend to generate the final SQL and return the query results.

[0151] This invention achieves automatic conversion from Groovy dot syntax query expressions to equivalent SQL query conditions through a combination of mechanisms including GroovyDSL entry, dynamic field metadata loading, dynamic attribute interception and field type assignment, AST semantic parsing, left and right value recognition, logical expression reduction, scope constraints, and QueryPayload compilation and execution.

[0152] In some implementations, dot syntax semantics are further extended to FORMULA type dynamically calculated fields and virtual reciprocallink fields that do not directly store associations, enabling query expressions to cover not only basic fields and ordinary association fields, but also formula calculation results and reverse virtual association results.

[0153] Compared to solutions based solely on dynamic SQL configuration, condition template assembly, or string replacement, this invention can directly support object navigation, condition filtering, unique object location, and subsequent chained navigation in complex business scenarios involving dynamic entities, dynamic fields, multi-level related objects, sub-table objects, and nested exists / notexists.

[0154] Therefore, this invention is particularly suitable for dynamic query scenarios that require simultaneous consideration of expressive power, execution accuracy, and maintainability, such as low-code platforms, dynamic form systems, and associated object management systems. It has high engineering application value and patent protection value.

[0155] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores static and dynamic information data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements the steps in the above method embodiments.

[0156] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the computer device to which the present invention is applied. A specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0157] In addition, the present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0158] In addition, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0159] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0160] This invention is not limited to the structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this invention is limited only by the appended claims.< / string> < / string> < / filtermodel> < / calculatequery> < / calculatequery> < / calculatequery> < / calculatequery> < / calculatequery> < / calculatequery> < / calculatevisit> < / map> < / map> < / filtermodel> < / filtermodel>

Claims

1. A query method using a structured query language, characterized in that, include: Receive the initial data object, and create and bind the root query object of the current project identifier through the script entry method; The entity context is initialized with the root query object as the current query object, and the entity field metadata corresponding to the target entity is loaded to establish a field mapping from field type to field type operator; In response to script access to the properties of the currently queried object, dynamic property interception is used to distinguish the field type of the accessed property in the field mapping. It then calls the corresponding field type operator based on the field type to perform parsing, in order to return the field value or generate the associated sub-query object; When the lower-level query object calls the filtering method and passes in the closure, the closure source code is parsed into an abstract syntax tree. The abstract syntax tree is traversed to distinguish between field paths and runtime parameter values, generating linear intermediate calculation units. The intermediate calculation units are then reduced to form a structured filtering model. Extract the identifier set of each object in the data object set of the lower-level query object, construct the scope filtering conditions, and combine the structured filtering model with the scope filtering conditions into a query payload; The query payload is compiled to generate an executable structured query language statement, which is then executed to obtain the query results. Depending on the query result type, the query results can be encapsulated into a new query object that supports continued navigation, or converted into a standardized list of results and returned.

2. The query method of the structured query language according to claim 1, characterized in that, The steps of initializing the entity context with the root query object as the current query object, loading the entity field metadata corresponding to the target entity, and establishing the field mapping from field type to field type operator include: Using the root query object as the current query object, set the corresponding entity context parameters and the current field reference relationship. The entity context parameters include the project identifier, business object identifier, and entity identifier. Determine whether the internal data of the currently queried object carries a unique identifier. If it does, query the entity details data and, based on whether the field that triggered the current navigation is a reference field, set the target entity corresponding to the next navigation scope, thereby initializing the field metadata and field operators. Based on the entity context parameters of the current navigation scope, the field service is invoked to query the list of field definitions under the target entity. If the list of field definitions is empty, a field metadata missing exception is thrown; otherwise, the list of field definitions is converted into a field mapping with field terms as keys and field definition objects as values.

3. The query method of the structured query language according to claim 1, characterized in that, The response to the script's access to the attribute of the current query object is to distinguish the field type of the accessed attribute in the field mapping through dynamic attribute interception. It then calls the corresponding field type operator based on the field type to perform parsing, returning the field value or generating related lower-level query objects, including: Listen for attribute access events of the currently queried object during script runtime, extract the accessed attribute name, and search for the field definition object corresponding to the attribute name in the current field mapping. If no field definition object is found, determine that the attribute name belongs to a business field or a built-in field. If the attribute name is neither a business field nor a built-in field, then there is no exception in the output field; If the attribute name is a built-in field, the field value is read directly from the current data object, and an empty value is returned if the current data object is empty; If the attribute name belongs to a business field, then the field type of that business field is read, and the corresponding field type operator is obtained based on the field type to perform field parsing and generate a new sub-query object.

4. The query method of the structured query language according to claim 3, characterized in that, If the attribute name belongs to a business field, then the field type of that business field is read, and the corresponding field type operator is obtained based on the field type to perform field parsing and generate a new lower-level query object, including: If the field type is identified as a basic field, then the corresponding field value is extracted from the data inside the current query object and a scalar value is returned; If the field type is identified as a single-value associated field, then it is determined whether the associated value is empty. If it is empty, an empty query object is returned as the lower-level query object. If it is not empty, a query object containing a single associated data is constructed as the lower-level query object. If the field type is identified as a multi-valued related field, then a query object containing multiple related data is constructed as a lower-level query object; If the field type is identified as a sub-table field, the sub-table entity identifier and business object identifier are parsed out according to the field configuration, and the sub-table query service is called to obtain the sub-table data list. If the list is empty, an empty query object is returned as the lower-level query object. If the list is not empty, the list is wrapped into a query object as the lower-level query object. If the field type identifies a dynamically calculated field, then the formula expression and dependent field values ​​are read, the expression calculator is called to perform dynamic calculations and return a scalar value; or in the filter expression, the comparison conditions for the dynamically calculated field are rewritten as query conditions for the dependent base fields of the dynamically calculated field. If the field type identifies a virtual backlink field, then the reference field and mapping field configuration are read, and the link values ​​in the data within the current query object are combined to construct the backlink payload and execute the peer entity query. If the query result is unique, a query object containing a single piece of data is constructed as the lower-level query object. If the query result is multiple, a query object containing multiple pieces of data is constructed as the lower-level query object. If no result is found, an empty query object is returned as the lower-level query object.

5. The query method of the structured query language according to claim 1, characterized in that, When the lower-level query object calls the filtering method and passes in a closure, the closure source code is parsed into an abstract syntax tree. The abstract syntax tree is traversed to distinguish between field paths and runtime parameter values, generating linear intermediate computation units. These intermediate computation units are then reduced to form a structured filtering model, including: When the current query object receives a filtering request or a unique object query request, it captures the closure object and closure source code string carried in the request, and calls the abstract syntax tree construction tool to parse the closure source code string into a complete abstract syntax tree structure. By recursively traversing each node of the abstract syntax tree through the syntax accessor, the left-hand field path and the right-hand runtime parameter of the expression are distinguished, the parameter binding is completed and the actual parameter value is parsed, and the current column identifier is recorded. Based on parameter binding and the parsing results of actual parameter values, logical operators, comparison operators and special query keywords are identified, and linear intermediate calculation units are generated in the parsing order. The logical expression is transformed using an infix-to-postfix algorithm, and then a stack-based reduction algorithm is used to transform the linear intermediate computational units into a tree-shaped structured filtering model.

6. The query method of the structured query language according to claim 5, characterized in that, The process involves recursively traversing each node of the abstract syntax tree using a syntax accessor, distinguishing between the lvalue field path and the rvalue runtime parameter of the expression, completing parameter binding, parsing the actual parameter value, and recording the current column identifier, including... When traversing a binary expression, obtain the position identifier of the right subexpression in the source code, which consists of the starting line number, starting column number, ending line number, and ending column number, and record this position identifier in the set of right value nodes. When an attribute expression is encountered, a position identifier for that attribute expression is generated, and it is determined whether the position identifier exists in the set of right-value nodes. If it exists, it is set as the rvalue parameter path. The corresponding source code segment is extracted from the closure source code, and after removing newline, tab and whitespace characters, the real parameter value is extracted in combination with the runtime binding parameters. If it does not exist, it is set as the lvalue field path. The object expression and property name are recursively read and concatenated in order from parent to child to form the field path string. The field path is recorded as the current column identifier and is used as the parent path prefix for inheritance when it exists or does not exist during recursive parsing.

7. The query method of the structured query language according to claim 5, characterized in that, The process of transforming logical expressions using an infix-to-postfix algorithm and then converting linear intermediate computational units into a tree-like structured filtering model using a stack-based reduction algorithm includes: Call the merge intermediate computation unit method, remove the outermost paired parentheses, traverse the list of linear intermediate computation units, identify consecutive column path, operator, and filter value triplet as a basic filter unit, and convert it into a filter model object by initializing the filter model. Call the method to parse the list of postfix expressions, and use the operator stack to convert infix logical AND, logical OR and bracket expressions into postfix expressions; The calculation method is called to perform stack-based calculation on the postfix expression. When a basic filtering unit is encountered, it is pushed onto the stack. When a logical AND is encountered, the filtering results on both sides of the stack are merged into the same condition list. When a logical OR is encountered, a compound OR condition node is constructed to obtain a list of structured filtering models.

8. The query method of the structured query language according to claim 1, characterized in that, The process of extracting the identifier set of each object within the data object set of the lower-level query object, constructing scope filtering conditions, and combining the structured filtering model with the scope filtering conditions into a query payload includes: Determine whether the data within the currently queried object is a single object or a collection of objects; If it is a collection of objects, then iterate through the current collection of objects to extract the identifiers of all objects and form a scope identifier set; if it is a single object, then directly extract the identifier of that object to construct a single-element scope identifier set. Based on the scope identifier set, construct a scope filtering condition with the field being identifier, the filtering type being set matching, and the value being the scope identifier set; The structured filtering model and the scope filtering conditions are written together into the query payload.

9. The query method of the structured query language according to claim 1, characterized in that, The process of compiling the query payload to generate an executable structured query language statement and executing it yields query results including: The query payload is serialized into a string, and the data service entry method is called, passing in the serialized query payload; In the backend service, the query payload is deserialized, and the business field token or dot syntax field path in the query payload is replaced with the actual stored field. The association query tree is constructed according to the association level in the field path, and join clauses, subqueries, or exist / not exist query fragments are generated. The structured filtering model is recursively compiled to generate conditional clause fragments and corresponding pre-compiled parameter lists. The main table, join, condition, sort, pagination, logical deletion filtering and data permission filtering are then merged to obtain the final executable structured query language statement. Execute the structured query language statement and return a list of query results.

10. The query method of the structured query language according to claim 1, characterized in that, The process of encapsulating query results into new query objects that support further navigation, or converting them into a standardized list of results and returning them, based on the query result type, includes: Identify the current request type as a list query request, a unique object query request, or a standardized output request; If it is a unique object query request, it is encapsulated into the corresponding root query object or lower-level query object according to the number of results, and a uniqueness exception check is performed. If it is a list query request, the result set is encapsulated into a group of query objects that can be chained and navigated. If it is a standardized output request, the internal results will be uniformly converted into a standard list structure; The encapsulated and processed result is sent back to the script caller.

11. A query system using a structured query language, characterized in that, include: The query entry construction module is used to receive the initial data object and create and bind the root query object of the current project identifier through the script entry method; The initialization loading module is used to initialize the entity context with the root query object as the current query object, load the entity field metadata corresponding to the target entity, and establish a field mapping from field type to field type operator; The dot syntax navigation module is used to respond to the script's access to the properties of the current query object, and distinguishes the field type of the accessed property in the field mapping through dynamic property interception; It then calls the corresponding field type operator based on the field type to perform parsing, in order to return the field value or generate the associated sub-query object; The filter model generation module is used to parse the closure source code into an abstract syntax tree when the lower-level query object calls the filter method and passes in the closure. It traverses the abstract syntax tree to distinguish field paths and runtime parameter values, generates linear intermediate calculation units, and reduces the intermediate calculation units to form a structured filter model. The query payload construction module is used to extract the identifier set of each object in the data object set of the lower-level query object, construct the scope filtering conditions, and combine the structured filtering model and the scope filtering conditions into the query payload. The backend compilation and execution module is used to compile the query payload, generate an executable structured query language statement, and execute it to obtain the query results; The result feedback parsing module is used to encapsulate the query results into a new query object that supports continued navigation, or to convert them into a standardized result list and return them, depending on the query result type.

12. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the query method of the structured query language according to any one of claims 1 to 10.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the query method of the structured query language according to any one of claims 1 to 10.

Images