Adaptive condition constructor device based on annotation

Abstract

The invention provides an annotation-based adaptive condition constructor device, and aims to realize automatic SQL (Structured Query Language) assembly and dynamic optimization of condition query. The device comprises a query request receiving module, a query object packaging module, a condition constructor component module and a database query module. According to the method, query conditions are marked through user-defined annotations, the annotation information extraction sub-module analyzes query types, data types and arithmetic logic, the SQL statement generation sub-module automatically generates SQL statements according to the annotations, and logic operation and sorting assembly are combined. The self-adaptive SQL optimization sub-module dynamically adjusts an SQL rule, preferentially processes a time consuming condition and an index field in combination with a database load condition, and improves the query efficiency. And the database query module executes the generated SQL and returns a structured query result. According to the method, code redundancy is reduced, the development efficiency is improved, the database load is remarkably reduced through an intelligent optimization strategy, and the method adapts to a complex query scene and has high efficiency, expansibility and flexibility.

Description

Technical Field

[0001] The present invention relates to the technical field of database query, in particular to an annotation-based adaptive condition builder device, which is specifically used to realize automatic SQL assembly and adaptive optimization of conditional query, and belongs to the cross-application field of software engineering and information processing technology. Background Art

[0002] In modern information systems, conditional query is an important part of database operations and is widely used in scenarios such as data screening, report generation, and information retrieval. However, in the existing technology, there are many technical problems and challenges in the implementation of conditional query, which urgently needs to be optimized and improved.

[0003] The implementation of traditional conditional queries is completed by manually splicing SQL statements. Developers need to make conditional judgments one by one based on the query parameters passed by the front end, and dynamically assemble SQL statements. Although this method is direct, due to the diversity of query conditions (such as range queries, fuzzy queries, sorting conditions, etc.), the code logic often appears very bloated. At the same time, this implementation method is prone to syntax errors due to problems such as symbol processing and parameter formatting, increasing the possibility of errors. In addition, whenever a new query condition is added or the logic is modified, the code needs to be adjusted accordingly, resulting in high maintenance costs, poor scalability, and difficulty in meeting the needs of complex scenarios.

[0004] As data complexity increases, the processing of multiple query parameters becomes more complicated. When the query conditions involve multiple fields and the logic is complex (for example, multiple AND / OR operations or nested conditions need to be processed), the traditional method requires parsing and splicing the query conditions one by one, which increases the difficulty of development and maintenance. The lack of a unified logic processing mechanism not only leads to code redundancy, but also makes it difficult to reuse and expand the code, further increasing the complexity of the system.

[0005] In terms of query performance, the traditional SQL generation method is based on static rules and cannot be dynamically optimized. This limitation will lead to many performance problems. For example, failure to give priority to index fields may significantly increase query time; fields with uneven distribution of condition values ​​may cause SQL execution efficiency to decrease; the generated SQL statements lack execution plan analysis and fail to optimize based on the actual operating status of the database, so they cannot be dynamically adjusted to adapt to changes in database load. These problems not only affect the query response speed, but also limit the overall performance of the system.

[0006] To solve the tedious problem of manually splicing SQL, some technologies try to simplify query operations by encapsulating database query frameworks (such as Hibernate, MyBatis, etc.). However, the flexibility of these frameworks in conditional query functions is still insufficient, which limits the free combination of query conditions and makes it difficult to meet the needs of complex scenarios. In addition, the learning curve of these frameworks is steep, and developers need to master a large number of configuration rules and usage methods, which has high operating costs. At the same time, the query optimization capabilities of the framework are also limited, and it is impossible to dynamically adjust the strategy according to the specific scenario, which further limits its wide application.

[0007] In order to simplify query condition processing, some technologies have introduced dynamic SQL generation functions. These technologies rely on string templates or simple rules to generate SQL statements. Although they reduce the workload of manually writing SQL to a certain extent, they also have obvious shortcomings. These methods have poor versatility and are difficult to adapt to the diverse needs of different systems. At the same time, due to the complexity of generating rules, the code maintenance cost is high, and it is easy to cause new problems when modifying rules. In addition, these technologies lack intelligent support and cannot be adaptively optimized in combination with the operating status of the database, making it difficult to fundamentally improve query efficiency.

[0008] In summary, the existing implementation methods of conditional query have obvious deficiencies in flexibility, ease of use and performance optimization. These problems seriously restrict the development efficiency and performance of the system. A more efficient and intelligent technical solution is urgently needed to solve these problems and meet the growing needs of modern information systems. Summary of the invention

[0009] In order to solve the above problems in the prior art, the present invention proposes an annotation-based adaptive condition builder device, which includes a query request receiving module, a query object encapsulation module, a condition builder component module and a database query module;

[0010] The query request receiving module is used to receive a conditional query request and pass the query condition as a structured parameter to the backend;

[0011] The query object encapsulation module is used to encapsulate the received query parameters into a query object; and process the attributes of the query object in a marking manner to identify the query conditions;

[0012] The condition builder component module performs query condition parsing and SQL generation, including an adaptive SQL optimization submodule, which dynamically adjusts SQL generation rules based on the database operation status; prioritizes high-weight fields to optimize query performance; analyzes query execution plans and continuously optimizes SQL generation strategies through a feedback mechanism;

[0013] The database query module is used to execute the generated SQL statement and return the structured query result.

[0014] The query request receiving module is used to receive conditional query requests, perform format verification and legality verification, and generate standardized query parameter objects; the module supports dynamic definition of the number and type of query conditions.

[0015] The query object encapsulation module is used to receive query parameters and encapsulate them into standardized query objects; the query object encapsulation module identifies the attributes of the query object by marking, the marking content includes query type, field data type, operation logic and sorting rules, and uses the parsing mechanism to generate a standardized structure for subsequent SQL generation module to call.

[0016] The condition builder component module also includes an annotation information extraction submodule, an SQL statement generation submodule and a logic operation and sorting assembly submodule; the annotation information extraction submodule is used to parse the tag information in the query object and extract the tag content as structured query condition data; the SQL statement generation submodule is used to automatically generate SQL statements compatible with the database based on the structured query condition data; generate SQL query logic according to the steps of condition parsing, statement splicing, format processing and parameter binding; the logic operation and sorting assembly submodule is used to assemble the query conditions according to the logic operation rules according to the query requirements, and generate sorting rules.

[0017] The adaptive SQL optimization submodule dynamically adjusts the priority of the query condition, and the formula used is:

[0018]

[0019] Among them, W i is the priority weight of field i, f i is the query frequency of the field, I i is the index fitness of the field, C i is the access cost of the field, and L is the current load index of the system.

[0020] The database query module includes:

[0021] The database connection management unit is used to maintain the database connection pool, obtain available connections from the connection pool before each query, and return the connection to the connection pool after the query is completed;

[0022] A parameter binding unit is used to bind the parameters contained in the generated SQL statement;

[0023] The query execution unit is used to connect to the database through the database driver interface and execute SQL statements, pass complete SQL statements and binding parameters, and receive the result set returned by the database;

[0024] A result parsing unit, used for parsing and packaging the result set;

[0025] The data encapsulation unit is used to encapsulate the processed query results into a unified structured data format.

[0026] Beneficial effects: The present invention realizes the automation and adaptive optimization of conditional queries through modular design, significantly improving query efficiency and system performance. Custom annotations reduce code redundancy, and adaptive SQL optimization dynamically adjusts query rules, reduces database load, and ensures efficient processing of complex conditional queries. At the same time, intelligent condition sorting and feedback mechanisms enhance the accuracy and continuous optimization capabilities of queries, providing the system with a highly flexible, stable, and scalable query solution. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The drawings described herein are used to provide a further understanding of the present invention and constitute a part of the present application, but do not constitute an improper limitation of the present invention. In the drawings:

[0028] Figure 1 A schematic diagram of the structure of an annotation-based adaptive condition builder device is shown. DETAILED DESCRIPTION

[0029] The present invention will be described in detail below in conjunction with the accompanying drawings and specific embodiments, wherein the illustrative embodiments and descriptions are only used to explain the present invention but are not intended to limit the present invention.

[0030] like Figure 1 As shown, this embodiment provides an annotation-based adaptive condition builder device. The device includes a query request receiving module 101, a query object encapsulation module 102, a condition builder component module 103 and a database query module 104. The above modules cooperate with each other to complete the automation and adaptive optimization of conditional query from query condition reception and parsing to SQL generation and query operation.

[0031] The query request receiving module 101 is used to receive conditional query requests from the front end. The front end sends request data containing query conditions to the back end through the API interface. The module processes the received query request through the following steps to ensure that the data can be correctly transmitted and parsed.

[0032] The query request receiving module 101 communicates with the front end through the standard HTTP protocol. This module defines an API interface that supports POST requests. The path of the interface can be set according to the naming convention of the actual system, such as " / api / query". The query conditions received by the interface are in JSON format, which has a clear structure and is easy to parse. The following is a request example:

[0033] The JSON format of the query request contains the following fields:

[0034] queryConditions: key-value pairs used to store all query conditions;

[0035] sortBy: used to specify the sorting field;

[0036] order: used to specify the sorting rule, such as "ASC" or "DESC".

[0037] The query request sample text is as follows:

[0038] The query conditions include:

[0039] The start date field "startDate" has a value of "2023-01-01";

[0040] The end date field "endDate" has a value of "2023-12-31";

[0041] Status field "status", value is "active".

[0042] The sorting field is "createdAt" and the sorting rule is descending "DESC".

[0043] After receiving the request data, the module first performs format verification and legality verification. Verification rules include but are not limited to:

[0044] Whether required fields exist, such as whether the "queryConditions" key is provided;

[0045] Whether the field value conforms to the expected data type and range, for example, the date field must be in a valid date format, and the sort field should be within the allowed range;

[0046] Check whether the data content is safe to prevent malicious injection, such as detecting whether there are illegal characters or SQL keywords.

[0047] After the verification is passed, the module will encapsulate the request data into the standard object required for subsequent processing; if the verification fails, the module will return an error message.

[0048] The query request receiving module parses the received JSON data into a query parameter object standardized by the backend. The parsing structure is:

[0049] "queryConditions": A list containing field names, operators, and field values. For example, it contains:

[0050] The field name is "startDate", the operator is "greater than or equal to", and the value is "2023-01-01";

[0051] The field name is "endDate", the operator is "less than or equal to", and the value is "2023-12-31";

[0052] The field name is "status", the operator is "equals", and the value is "active".

[0053] The parsed results can be directly called and processed by subsequent modules.

[0054] The query request receiving module 101 supports dynamic definition of the number and type of query conditions to avoid hard-coded restrictions on the interface. The module supports dynamic verification of allowed fields, allowing the system to quickly adapt to changes in the database table structure. For example, by querying the metadata table of the database, a list of allowed query fields and verification rules are generated to reduce manual intervention.

[0055] The module uses an asynchronous operation mechanism during processing to improve concurrency performance. At the same time, safety detection measures are used to restrict input parameters, for example:

[0056] Field content length limit;

[0057] Detect and remove potential SQL injection content;

[0058] Escape special characters to ensure system stability and security.

[0059] Through the above technical means, the query request receiving module 101 can efficiently and safely receive and parse the conditional query request submitted by the front end, generate a standardized query parameter object, and provide reliable basic support for the execution of subsequent modules.

[0060] The function of the query object encapsulation module 102 is to receive the query parameters transmitted by the backend and encapsulate them into a standardized query object. At the same time, the properties of the query object are marked by custom annotations, which contain key information such as query type, data type, operation type and sorting rules. These marking information is used for subsequent SQL parsing and generation, and is the basis for the module to realize automatic condition splicing.

[0061] The query object encapsulation module first defines a standardized query object class whose attributes correspond to the field names of the query parameters. For each field, the module adds custom annotations based on actual business needs to mark how the field is processed in SQL generation. For example, the following is a specific description of the encapsulation logic:

[0062] The query parameter startDate is used to filter the start time and needs to be queried in the "greater than or equal to" mode. The module adds an annotation to the startDate field, marking its query type as "greater than or equal to" and the data type as date.

[0063] The query parameter endDate is used to filter the end time and needs to be queried in the "less than or equal to" mode. The module adds an annotation to the endDate field, marking its query type as "less than or equal to" and the data type as date.

[0064] The encapsulated query object text description is as follows:

[0065] Field name: startDate;

[0066] Note: The query type is "greater than or equal to", the data type is DATE, and the operation type is AND;

[0067] Field name: endDate;

[0068] Note: The query type is "less than or equal to", the data type is DATE, and the operation type is AND;

[0069] Definition and Application of Annotations

[0070] The query object encapsulation module 102 uses custom annotations to mark the query fields. The core definition of the annotations includes the following:

[0071] queryType: used to specify the query operation type, such as equal to (EQ), greater than (GT), less than or equal to (LE), fuzzy query (LIKE), etc.

[0072] fieldType: used to specify the data type of the field, such as string (STRING), integer (INTEGER), date (DATE), etc.;

[0073] orderType: used to specify the sorting rules of the field, such as ascending (ASC) or descending (DESC).

[0074] The application of annotations is implemented through the reflection mechanism. The specific operations are as follows:

[0075] Annotation to define query object class:

[0076] The module adds annotations to each query field. For example, add an annotation to the startDate field to specify its query logic as "greater than or equal to". For the endDate field, the annotation is specified as "less than or equal to".

[0077] Parsing annotations using reflection mechanism:

[0078] The module obtains the annotation content of each field in the query object through reflection at runtime. The parsed results are stored in a standardized structure to facilitate subsequent SQL generation logic calls. For example, the parsed content is described as:

[0079] Field startDate: query type "greater than or equal to", field type DATE, operation type AND;

[0080] Field endDate: query type "less than or equal to", field type DATE, operation type AND.

[0081] The query object encapsulation module supports multiple annotation combinations in complex scenarios, such as:

[0082] Fuzzy query: For LIKE query, you can specify a matching prefix, suffix, or inclusion pattern;

[0083] Range query: Add two annotations to the same field, indicating the start value and the end value respectively, to achieve range filtering;

[0084] Sorting rules: automatically generate sort clauses by specifying ASC or DESC sort annotations for fields;

[0085] By using standardized query objects and custom annotations, the query object encapsulation module 102 can:

[0086] Extract query logic from code to make query condition definition more concise and clear;

[0087] Improve the reusability and scalability of query logic, eliminating the need to manually implement complex conditional splicing in the code;

[0088] Provides a flexible field tagging mechanism to adapt to diverse query requirements and improve system maintainability.

[0089] In summary, the query object encapsulation module 102 provides flexible and efficient basic support for subsequent SQL parsing and generation through custom annotations and standardized encapsulation.

[0090] The condition builder component module 103 is the core module of the device, which is used to realize the analysis of query conditions and the automatic generation of SQL statements. This module completes the whole process from annotation analysis to SQL logic assembly through the division of labor and cooperation of submodules, ensuring that the generated SQL statements are compatible with database operations and meet the needs of complex query scenarios.

[0091] The main function of the annotation information extraction submodule is to parse the custom annotations defined in the query object, extract the query configuration information therein, and convert it into structured query condition data.

[0092] This module uses the reflection mechanism to scan the properties of the query object one by one and identify the annotations defined on each field. The extracted annotation information includes the following key elements:

[0093] Query type: logical operators representing conditions, such as equal to, not equal to, greater than, less than or equal to, etc.;

[0094] Data type: specifies the data format of the field, such as string, date, integer, etc.

[0095] Operation type: specifies the logical relationship between multiple query conditions, such as AND or OR.

[0096] Sort Type: Defines the sorting rule for the field, such as ascending or descending.

[0097] After parsing is completed, the submodule stores the annotation information as a structured data structure, such as a key-value pair or a mapping table, to facilitate subsequent submodule calls. For example, the parsed structure can be expressed as:

[0098] The field name is "startDate", the query type is "greater than or equal to", the data type is date, and the operation type is "and";

[0099] The field name is "endDate", the query type is "less than or equal to", the data type is date, and the operation type is "and";

[0100] The field name is "status", the query type is "equal to", the data type is string, and the operation type is "and".

[0101] The core feature of this module is its strong flexibility. It can adapt to the diverse fields and annotation configurations in different query objects, and provide basic support for dynamic parsing and flexible generation of conditions.

[0102] The SQL statement generation submodule automatically generates SQL statements compatible with the database based on the structured data provided by the annotation information extraction submodule.

[0103] The build process consists of the following steps:

[0104] Conditional parsing: traverse each field in the structured data and generate corresponding SQL conditions based on the query type and data type of the field. For example, the field "startDate" will generate the condition "startDate>=?".

[0105] Statement concatenation: logically combine the parsed query conditions according to the operation type (such as "and" or "or"). For example, if the query conditions include "startDate>=?" and "endDate<=?", the concatenated statement is "WHEREstartDate>=? AND endDate<=?".

[0106] Format processing: Perform necessary formatting on the parameters according to the field data type and database compatibility requirements. For example, a date field may need to be converted to a standard database format.

[0107] Parameter binding: Bind query parameters to the generated SQL statement to ensure that SQL injection issues are avoided. For example, for the condition "startDate>=?", the bound parameter value is "2023-01-01".

[0108] The resulting SQL statement can be directly applied to database query operations. For example, when the query conditions include "startDate" and "endDate", the generated SQL statement is:

[0109] SELECT*FROM table WHERE startDate>='2023-01-01'AND endDate<='2023-12-31'ORDER BY createdAt DESC.

[0110] The function of the logical operation and sorting assembly submodule is to logically assemble the parsed query conditions according to the operation logic and sorting rules defined in the annotations to build a complete query logic.

[0111] Logical operation assembly: For multiple query conditions, the module will logically combine the conditions according to the operation type specified in the annotation (such as "and" or "or"). For example, when multiple fields need to be fuzzy searched, you can choose to connect the conditions with "and" or "or" to generate logic similar to the following:

[0112] WHERE name LIKE'%value%'AND description LIKE'%value%'

[0113] Sorting rule assembly: The module will add a sorting clause to the generated SQL statement according to the sorting type defined in the annotation. For example, if the annotation specifies that the sorting of the field "createdAt" is in descending order, the generated sorting statement is "ORDER BY createdAt DESC". For multi-field sorting, the module supports dynamic extension rules, for example:

[0114] ORDER BY createdAt DESC,updatedAt ASC

[0115] Through the above steps, the conditional builder component module 103 can efficiently complete the entire process from annotation parsing to SQL generation, provide automated support for complex conditional queries, and ensure the superiority of the generated SQL statements in performance and compatibility.

[0116] The core function of the adaptive SQL optimization submodule is to monitor the database operation status in real time, dynamically adjust the SQL generation rules to improve query efficiency, reduce database load pressure, and continuously optimize query performance.

[0117] The adaptive SQL optimization submodule obtains real-time performance indicators by integrating database performance monitoring tools (such as Prometheus, Zabbix, or database native monitoring tools). These performance indicators include but are not limited to:

[0118] Database response time: refers to the time it takes for a single query to be received and returned;

[0119] Database load: such as CPU usage, memory usage, IO read and write rates, etc.

[0120] Query plan execution cost: indicates the amount of resources consumed by the database to execute a specific SQL statement;

[0121] Index usage: Statistics on the access frequency and query efficiency of index fields.

[0122] The module obtains the above indicators through the API or database driver interface and stores them in a structured form in memory for real-time analysis. For example, the module can determine whether the database load is at its peak by "response time > threshold".

[0123] Based on the monitored database performance indicators, the adaptive SQL optimization submodule dynamically adjusts the SQL generation rules to maximize query efficiency and reduce database pressure. The adjustment rules include the following points:

[0124] Prioritize optimization of index field query conditions: When the database load is high, the module prioritizes the index fields in the query conditions to the front of the SQL statement to ensure that the database reduces the scanning range as much as possible during the index retrieval phase. For example, the indexed field "userId" is prioritized as WHERE userId = ?.

[0125] Execute complex conditions step by step: For complex query conditions, the module will split them into multiple simple queries, execute them step by step, and merge the results. For example, for the condition (A OR B) AND C, it can be split into two sub-queries SELECT*FROM tableWHERE A AND C and SELECT*FROM table WHERE B AND C, and then merge the results to reduce the immediate load on the database.

[0126] Dynamic sorting optimization: Automatically adjust the priority of the ORDER BY clause according to the sorting characteristics of the index to avoid unnecessary full table scans. For example, when the query condition contains multi-field sorting, the module prioritizes the use of index fields supported by the database for sorting rather than calculated sorting.

[0127] To further enhance the intelligent adjustment capability of SQL generation rules, the adaptive SQL optimization submodule embeds a dynamic load adjustment weight formula to evaluate the priority of each query condition, thereby optimizing the SQL generation order. The formula is as follows:

[0128]

[0129] in:

[0130] W i : The priority weight of field i;

[0131] f i : The query frequency of field i, which indicates the number of times the field appears in historical queries, reflecting its importance;

[0132] I i : The index adaptability of field i. If the field has an index, the value is 1; if there is no index, the value is 0.5;

[0133] C i : The access cost of field i, obtained from the query execution plan, represents the resource overhead required to scan this field;

[0134] L: The current load index of the system, which is calculated based on indicators such as the database's CPU usage and memory usage.

[0135] By calculating the weight W of each field i, the module can intelligently determine the execution order of query conditions and give priority to fields with larger weights to reduce the database scan scope. For example:

[0136] When the query frequency of the field "startDate" is high (f i Large), indexed (I i =1), low access cost (C i When the system load is low (L is small), its weight W i The value will be larger, so this field will be used as the query condition first when generating SQL statements.

[0137] After the SQL statement is generated, the module evaluates the execution efficiency of the SQL statement through the database execution plan analysis tool (such as MySQL's EXPLAIN command or PostgreSQL's EXPLAIN ANALYZE). The specific analysis steps include:

[0138] Get the execution plan output and analyze the SQL access path, including index usage, number of full table scans, and depth of nested loops;

[0139] Check the scan scope and make sure the query filter range is as small as possible;

[0140] Optimize the query statement based on the "cost" indicator of the execution plan, such as by adding index hints or adjusting the order of conditions to reduce the execution cost.

[0141] The results of the execution plan analysis are stored as optimization records for subsequent SQL generation rule adjustments. For example, if the analysis finds that there are unindexed fields in the WHERE condition, the module will automatically prompt the developer or adjust the index strategy.

[0142] The adaptive SQL optimization submodule supports continuous optimization based on historical performance data. The module stores the execution time, execution plan, and results of each query in a performance record table, and regularly aggregates and analyzes historical data to identify potential performance issues and improve optimization strategies. For example:

[0143] Identify high-frequency query patterns through data aggregation analysis, add caches for common queries or generate pre-computed views;

[0144] Adjust dynamic optimization rules based on historical records. For example, when the query response time of a specific field exceeds a threshold, prioritize it in the index optimization scope.

[0145] Automatically generate optimization reports to help developers analyze performance bottlenecks and optimize database structures.

[0146] Through the above steps, the adaptive SQL optimization submodule realizes dynamic adaptation and continuous performance improvement for complex query scenarios, effectively reduces database resource consumption, improves query efficiency, and enhances the robustness and scalability of the system. In particular, by dynamically adjusting the weight formula W i With the introduction of , the module can intelligently optimize the query condition order based on real-time load and field characteristics.

[0147] The database query module 104 is responsible for receiving the SQL statements generated by the condition builder component module, executing database operations, and returning the query results to the front end in the form of structured data. This module focuses on efficiency, security and compatibility during execution to ensure the accuracy of the query results and the overall performance of the system.

[0148] The database query module 104 connects to the database through the database driver interface and executes SQL statements. The execution steps include the following:

[0149] Database connection management: The module maintains a database connection pool to improve concurrency performance and resource utilization. Before each query, it obtains an available connection from the connection pool and returns the connection after the query is completed.

[0150] Parameter binding: The module binds the parameters contained in the generated SQL statement to avoid SQL injection risks. For example, the value of the placeholder in the SQL statement, such as the date "2023-01-01", will be dynamically injected into the query parameter.

[0151] Execute query: The module calls the query method of the database driver interface, passing the complete SQL statement and binding parameters. After the query is executed, the result set returned by the database is encapsulated into a unified data structure.

[0152] The module parses and encapsulates the result set returned by the database to ensure that the front end can use the query results in a structured form. The processing steps are as follows:

[0153] Result set parsing: The module extracts data from the result set row by row based on the field list specified in the query statement. For example, if the query fields include "id", "name", and "createdAt", the module will parse and extract the values ​​of these columns.

[0154] Data type conversion: The module converts the data in the result set according to the data type of the query field. For example, date type data will be converted to the date object format supported by the system, and number type data will be converted to integer or floating point objects.

[0155] Exception handling: During the result parsing process, if the field type does not match or the query result is empty, the module will log and return an error message. For example, when the value of the date field does not conform to the expected format, the module will prompt "Invalid date format".

[0156] The processed query results are encapsulated into a unified structured format, such as JSON or XML, so that the front end can use them directly.

[0157] JSON format: The module encapsulates the query results as an array of key-value pairs, and each row of data is represented as an object. For example:

[0158] Query results: Contains two records, representing the users "Alice" and "Bob", and their respective creation times.

[0159] XML format: The module also supports organizing query results in XML format, for example:

[0160] Each record uses <row>The label contains the field name and the corresponding value.

[0161] The database query module 104 combines performance and security optimization techniques during execution to improve query efficiency and prevent security risks. Specific measures include:

[0162] Batch query and paging support: When processing large amounts of data, the module uses paging technology to avoid loading a large amount of data at one time. For example, for a paging query SQL statement, the query results will be returned in logical segments of "displaying 100 items per page".

[0163] Concurrent query optimization: The module combines the database connection pool configuration to allow multiple query tasks to be executed concurrently and avoid connection conflicts through resource allocation.

[0164] Security protection: The module uses parameterized query technology to prevent users from entering malicious SQL content and ensure system data security.

[0165] The module adds a complete error handling mechanism during execution to ensure system stability:

[0166] Connection error: If the database connection pool is exhausted or the connection fails, the module returns an error message "Database connection error".

[0167] Query error: If the SQL syntax is wrong or parameter binding fails, the module records detailed logs and returns the error message "SQL execution error".

[0168] Result processing error: If the query result parsing fails (for example, the field data type does not match), the module records the relevant exception and prompts "Result parsing error".

[0169] Through the above implementation steps, the database query module 104 can efficiently and reliably execute SQL statements and return query results, providing structured data support for the front end. The module design ensures the security, compatibility and scalability of query operations and meets the needs of diverse application scenarios.

[0170] The above description is only a preferred embodiment of the present invention, so all equivalent changes or modifications made according to the structure, characteristics and principles described in the scope of the patent application of the present invention are included in the scope of the patent application of the present invention.< / row>

Claims

1. An annotation-based adaptive condition builder device, characterized in that: The adaptive condition builder device includes a query request receiving module, a query object encapsulation module, a condition builder component module and a database query module; The query request receiving module is used to receive a conditional query request and pass the query condition as a structured parameter to the backend; The query object encapsulation module is used to encapsulate the received query parameters into a query object; And the attributes of the query object are processed by marking to identify the query conditions; The condition builder component module performs query condition parsing and SQL generation, including an adaptive SQL optimization submodule, which dynamically adjusts SQL generation rules based on the database operation status; prioritizes high-weight fields to optimize query performance; analyzes query execution plans and continuously optimizes SQL generation strategies through a feedback mechanism; The database query module is used to execute the generated SQL statement and return the structured query result.

2. The annotation-based adaptive condition builder device according to claim 1, characterized in that: The query request receiving module is used to receive conditional query requests, perform format verification and legality verification, and generate standardized query parameter objects; the module supports dynamic definition of the number and type of query conditions.

3. The annotation-based adaptive condition builder device according to claim 1, characterized in that: The query object encapsulation module is used to receive query parameters and encapsulate them into a standardized query object; The query object encapsulation module identifies the attributes of the query object by marking, the marking content includes the query type, field data type, operation logic and sorting rules, and uses the parsing mechanism to generate a standardized structure for subsequent SQL generation module to call.

4. The annotation-based adaptive condition builder device according to claim 1, characterized in that: The condition builder component module also includes an annotation information extraction submodule, an SQL statement generation submodule and a logic operation and sorting assembly submodule; the annotation information extraction submodule is used to parse the tag information in the query object and extract the tag content as structured query condition data; The SQL statement generation submodule is used to automatically generate SQL statements compatible with the database according to the structured query condition data; generate SQL query logic according to the steps of condition analysis, statement splicing, format processing and parameter binding; The logic operation and sorting assembly submodule is used to assemble the query conditions according to the logic operation rules and generate the sorting rules according to the query requirements.

5. The annotation-based adaptive condition builder device according to claim 1 or 4, characterized in that: The adaptive SQL optimization submodule dynamically adjusts the priority of the query condition, and the formula used is: Among them, W i is the priority weight of field i, f i is the query frequency of the field, I i is the index fitness of the field, C i is the access cost of the field, and L is the current load index of the system.

6. The annotation-based adaptive condition builder device according to claim 1, characterized in that: The database query module includes: The database connection management unit is used to maintain the database connection pool, obtain available connections from the connection pool before each query, and return the connection to the connection pool after the query is completed; A parameter binding unit is used to bind the parameters contained in the generated SQL statement; The query execution unit is used to connect to the database through the database driver interface and execute SQL statements, pass complete SQL statements and binding parameters, and receive the result set returned by the database; A result parsing unit, used for parsing and packaging the result set; The data encapsulation unit is used to encapsulate the processed query results into a unified structured data format.

Images