Method for simplifying construction of complex query conditions of distributed file storage database

Abstract

The application discloses a method for simplifying the construction of complex query conditions of a distributed file storage database, and comprises the following steps: receiving an incoming example object, judging whether the example object is empty or not; using flatFieldMeta() to parse the attributes of the example object into a FieldMeta object list through recursion; traversing the FieldMeta object list, filtering invalid metadata; traversing the FieldMeta object list, calling a metadata class according to the attribute name and value of each valid metadata, and converting the metadata object into a corresponding Criteria object; and using all the Criteria objects to dynamically generate a final query condition by using an andOperator. The application can construct the query condition of the distributed file storage database in a simple, efficient and flexible way, reduce code repetition, improve the readability and maintainability of the code, and facilitate the processing of dynamic query conditions.

Description

Technical Field

[0001] This invention relates to a method for constructing complex query conditions for distributed file storage databases. Background Technology

[0002] In distributed file storage database operations, constructing query conditions is a common and important task.

[0003] Existing technical solutions typically involve manually writing distributed file storage database query statements or using the basic APIs provided by database operation frameworks to construct query conditions.

[0004] For example, when using the Spring Data distributed file storage database framework, developers may need to manually create Criteria objects and add query conditions one by one, like this: Criteria criteria=Criteria.where("field1").is("value1").and("field2").gt(10).

[0005] For complex queries, such as multi-condition combined queries and nested object queries, this approach requires manually creating and combining Criteria objects multiple times when constructing complex query conditions. This necessitates writing a large amount of repetitive code, leading to severe code redundancy. Furthermore, the extensive manual concatenation of code makes the query condition logic unclear, difficult to understand and maintain, resulting in poor code readability and maintainability. Additionally, for scenarios with dynamically generated query conditions, existing implementations often require developers to manually handle various complex logics, which is difficult and requires writing a large amount of condition judgment code, making it prone to errors. Summary of the Invention

[0006] The purpose of this invention is to provide a technical solution for simplifying the construction of complex query conditions in distributed file storage databases, addressing the shortcomings of existing technologies. This solution not only reduces the amount of code manually written for Criteria objects by encapsulating the query condition construction logic, making the code more concise, but also uses a unified interface and method to construct query conditions, making the query logic clearer, easier to understand, and more readable. Furthermore, it can dynamically generate complex query conditions based on different inputs, supports multiple comparison methods and combined queries, and offers high flexibility.

[0007] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0008] A method for simplifying complex query conditions in distributed file storage databases is used. This method is based on dynamic construction and includes the following steps:

[0009] Step 1: Receive the passed-in example object, determine whether the example object is empty, and if it is empty, return an empty Criteria object;

[0010] Step 2: Use flatFieldMeta() to recursively parse the properties of the example object into a list of FieldMeta objects;

[0011] Step 3: Traverse the list of FieldMeta objects and filter out invalid metadata;

[0012] Step 4: Traverse the list of FieldMeta objects, and based on the attribute name and value of each valid metadata, call the metadata class to convert the metadata object into the corresponding Criteria object;

[0013] Step 5: Use andOperator to dynamically generate the final query conditions for all Criteria objects.

[0014] The present invention, by adopting the above-described technical solution, has the following beneficial effects:

[0015] This invention not only reduces the amount of code manually written for Criteria objects by encapsulating the logic for constructing query conditions, making the code concise, but also uses a unified interface and method to construct query conditions, making the query logic clearer, easier to understand, and more readable. At the same time, it can dynamically generate complex query conditions based on different inputs, supports multiple comparison methods and combined queries, and is highly flexible. Attached Figure Description

[0016] The present invention will be further described below with reference to the accompanying drawings:

[0017] Figure 1 This is a flowchart illustrating the method for constructing complex query conditions in a distributed file storage database according to the present invention.

[0018] Figure 2 This is a flowchart illustrating how the flatFieldMeta() function recursively parses the properties of an example object into a list of FieldMeta objects in this invention.

[0019] Figure 3 This is a flowchart illustrating how the `flesh()` method is called to parse attribute information and encapsulate it into a field metadata class in this invention.

[0020] Figure 4 This is a flowchart illustrating the process of calling the member() method to parse its subfields in this invention;

[0021] Figure 5 This is a flowchart of the combined construction method based on simplified distributed file storage database multi-condition query in this invention;

[0022] Figure 6 This is a schematic diagram of the core class in this invention;

[0023] Figure 7 This is a logical call diagram of the buildWith method in this invention;

[0024] Figure 8 This is an example diagram illustrating the effect of the buildWith method in this invention;

[0025] Figure 9 This is a logical call diagram of the buildComboCriteria method in this invention;

[0026] Figure 10 This is a sequence diagram of the call to the construction method in this invention. Detailed Implementation

[0027] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0028] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0030] ;

[0031] like Figure 1 , Figures 6 to 10 As shown, this invention provides a method for constructing complex query conditions in a distributed file storage database. The method is characterized by dynamic construction and includes the following steps:

[0032] Step 1: Receive the passed-in instance object and determine if the instance object is empty. If it is empty, return an empty Criteria object. This is to prevent accidental triggering. If an empty instance object enters the following process, it will cause a null pointer exception, so we check in advance to prevent it from entering the following process.

[0033] Step 2: Use flatFieldMeta() to recursively parse the properties of the example object into a list of FieldMeta objects;

[0034] When using flatFieldMeta() to recursively parse the properties of an example object into a list of field metadata class objects, the properties of the example object are encapsulated into field metadata classes, and the property name conversion and condition type parsing are handled.

[0035] like Figure 2 As shown, using flatFieldMeta() to recursively parse the properties of an example object into a list of FieldMeta objects specifically includes the following steps:

[0036] Step 2.1 Call the `flesh()` method to parse the attribute information and encapsulate it into a field metadata class;

[0037] like Figure 3 As shown, calling the `flesh()` method to parse attribute information and encapsulate it into a field metadata class includes the following steps:

[0038] Step 2.1.1 Parse condition type and attribute name: Automatically identify special query suffixes (such as "Lt" indicating less than condition). The identification basis is whether the suffix of the attribute name is one of the 12 preset recognizable condition types. If so, the attribute name is decomposed into field name + query condition type. If not, it means that the attribute name has no suffix, and the default query method is EQ.

[0039] Step 2.1.2 Handling attribute name conversion: Convert the attribute name to the corresponding field name in the database according to the defined naming convention (such as camelCard to underscore). For example, if the attribute name is idCardNo, it is converted to the corresponding database field name: id_card_no. The reason for the conversion is based on the conventional development habit that the attribute name in the code is in camelCard form, while the field name in the database is in underscore form.

[0040] Step 2.1.3 Encapsulate into a metadata class: field name equals the decomposed attribute name, field query method equals the condition type, and field value equals the attribute value.

[0041] Step 2.2 Take the metadata class returned by the flesh() method as the parent metadata class and call the member() method to parse its subfields;

[0042] like Figure 4 As shown, calling the member() method to parse its subfields specifically includes the following steps:

[0043] Step 2.2.1 If the field value of the class is empty, or the field is a leaf node field, then there are no child fields. The method to determine whether it is a leaf node isLeaf(). Its principle is to determine that the field value is not empty and that the field value type is a basic type (such as string, number, date and other non-expandable types).

[0044] Step 2.2.2 Determine the type of the field value. If it is a key-value pair type (Map), convert each key-value pair into a metadata class object and add it to the subfield list.

[0045] Step 2.2.3 Determine the type of the field value. If it is an object (JavaBean) defined in the code, use reflection to get all the properties of the object and iterate through the object properties.

[0046] When iterating over object properties: (1) Determine if the property uses the @Mongolgnore annotation. If it does, ignore the property, indicating that the property is not needed for database queries; (2) Encapsulate the property into a metadata class.

[0047] The data class encapsulates metadata such as field names, comparison methods, field values, and parent fields, and is responsible for converting fields into corresponding database query objects (Criteria).

[0048] This conversion method offers the following advantages: it automatically handles parent-child field relationships, supports automatic conversion of various naming styles (such as camelCase to underscore), automatically identifies special query suffixes (such as "Lt" indicating a less than condition), supports custom annotations (@Mongolgnore) to ignore specific fields, and supports 12 query condition types through field comparison method enumeration (CompareMethod). These 12 query condition types include: LT("Lt") less than, LTE("Lte") less than or equal to, EQ("Is") equal to, NE("Ne") not equal to, GT("Gt") greater than, GTE("Gte") greater than or equal to, IN("In") within range, NIN("Nin") outside range, Null("IsNull") field is empty, ContainWith("Cw") fuzzy query, StartWith("Sw") starting with a character, and Has("Has") containing. Each condition type is automatically converted to the corresponding distributed file storage database query object (Criteria), and it also includes special query type handling, such as converting the MoreThen condition to an Exists query.

[0049] Step 2.3 Iterate through the child metadata class returned by the member() method and process the parent and child fields;

[0050] The specific steps for handling parent and child fields are as follows:

[0051] Step 2.3.1 Determine the parent field name of the child field's metadata class: If the parent field is empty, then assign the parent field name to the field name of the parent metadata class;

[0052] Step 2.3.2 Determine the parent field name of the child field's metadata class: If the parent field name is not empty, then assign the value to the field name of the child field's metadata class. The field name of the child field's metadata class is: the parent field name of the child field's metadata class.the original field name, that is, the field name of the child field's metadata class needs to be connected with "." between the parent field name and the original field name.

[0053] Step 2.4 returns a list of all leaf node metadata class objects. The leaf node metadata class is formed by accumulating the sub-metadata classes returned by recursively calling the `member()` method on all attributes, only retrieving sub-fields whose sub-fields are leaf nodes, and combining them into a single list of leaf node metadata class objects.

[0054] Step 3: Traverse the list of FieldMeta objects and filter out invalid metadata;

[0055] Step 3.1: Filter metadata objects whose query field values ​​are empty, that is, delete metadata objects that do not need to be queried;

[0056] Step 3.2: The filtering query method is to use metadata objects where IN("In") is within the range and NIN("Nin") is outside the range, but the field values ​​are not arrays. A range query is only valid if the field values ​​are an array. For example, an age metadata object (field name = age, query condition type = IN, field value = 20) has field values ​​that are not an array, making it a invalid query and requiring filtering. To make it a valid query, the field values ​​need to be modified to: [20, 30].

[0057] Step 4: Traverse the list of FieldMeta objects, and based on the attribute name and value of each valid metadata, call the metadata class to convert the metadata object into the corresponding Criteria object;

[0058] Calling the metadata class to convert a metadata object into a corresponding Criteria object specifically includes:

[0059] Step 4.1 The field names of the metadata object correspond to the database field names of the query conditions of the Criteria object;

[0060] Step 4.2 The field values ​​of the metadata object correspond to the database field values ​​of the query conditions of the Criteria object;

[0061] Step 4.3 The query methods for metadata objects correspond to the query methods for Criteria object query conditions.

[0062] For example, in the name metadata class, the field name of the metadata object is "name", the database field name of the corresponding Criteria object query condition is "name", the field value of the metadata object is "Zhang San", the database field value of the corresponding Criteria object query condition is "Zhang San", the query method of the metadata object is "equal to", and the query method of the corresponding Criteria object query condition is "is".

[0063] The age metadata class has a field name of "age" for the metadata object, and the corresponding database field name for the Criteria object query condition is "age". The field value of the metadata object is "25", and the corresponding database field value for the Criteria object query condition is 25. The query method of the metadata object is "less than", and the query method for the Criteria object query condition is "Lt".

[0064] The metadata class has a field named "Hobbies". The corresponding database field name for the Criteria object's query condition is "Hobbies". The metadata object's field value is "Playing Ball, Singing, Dancing". The corresponding database field values ​​for the Criteria object's query condition are "Playing Ball", "Singing", and "Dancing". The metadata object's query method is "Within Range". The corresponding query method for the Criteria object's query condition is "in".

[0065] If a field in the metadata object is named "School", and the corresponding database field in the Criteria object's query condition is also named "School", and the field value of the metadata object is "empty", then the object should be deleted and not participate in the final query.

[0066] Step 5: Use andOperator to dynamically generate the final query conditions for all Criteria objects.

[0067] This construction method is simple in steps. It not only reduces the amount of code to manually write Criteria objects by encapsulating the construction logic of query conditions, making the code concise, but also uses a unified interface and method to construct query conditions, making the query logic clearer, easier to understand, and more readable. At the same time, it can dynamically generate complex query conditions based on different inputs, supports multiple comparison methods and combined queries, and is highly flexible.

[0068] like Figure 5 As shown, the construction method is based on a simplified combination of multi-condition queries for distributed file storage databases, and includes the following steps:

[0069] Step 1: Receive and iterate through the input array. Each element in the array is a key-value pair. Multiple fields within the same key-value pair are joined using an AND (logical AND) condition, while multiple key-value pairs are joined using an OR (logical OR) condition. (This is done using a List...) <Map<String,List <any>>> Input structure, where each Map represents a set of query conditions;

[0070] List <Map<String,List <any>In the >> structure, each element of the array is a key-value pair (Map), representing a set of conditions connected by AND. The key of each key-value pair is a string, and the value is an array of arbitrary objects. Concatenation is only performed when the array is not empty.

[0071] Step 2: Filter out key-value pairs with empty values, and convert each valid key-value pair into a Criteria object. The query field name of the Criteria object is the key of the key-value pair, the query condition type of the Criteria object is "in", and the query field value of the Criteria object is the value of the key-value pair.

[0072] Step 3: Combine all Criteria objects in a single key-value pair using the andOperator to generate query conditions;

[0073] Step 4: Combine all AND conditions using orOperator to generate the final query conditions.

[0074] The construction method is based on dynamic construction and composite construction, and includes the following steps:

[0075] Call the dynamic construction method to obtain the returned database query object Criteria1;

[0076] Call the composite construction method to obtain the returned database query object Criteria2;

[0077] Create a new query object `Criteria3` to combine the results. Call `andOperator` to combine `Criteria1` and `Criteria2` into a single query condition. When using dynamic or composite construction methods, you can call the dynamic construction method first and then the composite construction method, or vice versa.

[0078] The construction method uses the CriteriaBuilder utility class to build the query conditions for the distributed file storage database.

[0079] Here is an example of using the CriteriaBuilder class:

[0080] Kotlin

[0081] 1. The implementation process of the buildWith method:

[0082] fun buildWith(example: Any?): Criteria{

[0083] / / Call flatFieldMeta() to iterate through the properties of example

[0084] val fieldCriteriaList=flatFieldMeta(FieldMeta(name="root",value=example))

[0085] .filter{

[0086] / / Filter properties that do not need to be processed

[0087] }

[0088] .flatMap{

[0089] / / Convert the metadata fieldMeta into a query object

[0090] listOf(it.method!!,assemble(it.fullPath(),it.value!!)))

[0091] }

[0092] / / Combine all criteria into a single query condition

[0093] Return Criteria().andOperator(*fieldCriteriaList .toTypedArray())

[0094] }

[0095] The implementation process of the flatFieldMeta() method is as follows:

[0096] fun flatFieldMeta(meta: FieldMeta): List <fieldmeta>{

[0097] val list = mutableListOf <fieldmeta>()

[0098] val queue = LinkedList <fieldmeta>()

[0099] queue.push(meta.flesh())

[0100] while (queue.isNotEmpty()) {

[0101] val fieldMeta = queue.poll()

[0102] list.add(fieldMeta.flesh())

[0103] fieldMeta.members().forEach {

[0104] it.parentName = buildParentName(it)

[0105] queue.push(it)

[0106] }

[0107] }

[0108] return list.filter { it.isLeaf()&&it.value != null}

[0109] }

[0110] 2. Example of using the buildWith method

[0111] / / Example object

[0112] Input object: User{name="Alice", age=25, ignoreField=null}

[0113] Processing steps:

[0114] ① Filter out ignoreField

[0115] ② Generate two Criteria:

[0116] - Criteria("name", "Alice")

[0117] - Criteria("age", 25)

[0118] ③ The combination is: andOperator(Criteria1, Criteria2)

[0119] Final query criteria: { "$and": [ { "name": "Alice"}, { "age": 25} ]}

[0120] 3. Example of combined query conditions

[0121] Effect illustration:

[0122] Input List <map>: [

[0124] { "name": ["Alice", "Bob"], "age":

[20] },

[0125] { "role": ["Admin"]} ]

[0127] Processing steps:

[0128] 1. First Map transformation:

[0129] -andOperator(

[0130] Criteria("name", ["Alice", "Bob"]),

[0131] Criteria("age",

[20] ) )

[0133] →{ "$and": [ { "name": { "$in": ["Alice", "Bob"]}}, { "age": 20}]}

[0134] 2. Second Map transformation:

[0135] -{ "$or": [ { "role": "Admin"} ]}

[0136] 3. Final combination:

[0137] { "$or": [

[0138] { "$and": [ ... ]},

[0139] { "role": "Admin"}

[0140] ]}.

[0141] The above are merely specific embodiments of the present invention, but the technical features of the present invention are not limited thereto. Any simple changes, equivalent substitutions, or modifications made based on the present invention to achieve substantially the same technical effect are all covered within the protection scope of the present invention.< / map> < / fieldmeta> < / fieldmeta> < / fieldmeta> < / any> < / any>

Claims

1. A method for simplifying the construction of complex query conditions in a distributed file storage database, characterized in that: The construction method is based on dynamic construction and includes the following steps: Step 1: Receive the passed-in example object, determine whether the example object is empty, and if it is empty, return an empty Criteria object; Step 2: Use flatFieldMeta() to recursively parse the properties of the example object into a list of FieldMeta objects; Step 3: Traverse the list of FieldMeta objects and filter out invalid metadata; Step 4: Traverse the list of FieldMeta objects, and based on the attribute name and value of each valid metadata, call the metadata class to convert the metadata object into the corresponding Criteria object; Step 5: Use andOperator to dynamically generate the final query conditions for all Criteria objects.

2. The method for constructing complex query conditions for distributed file storage databases according to claim 1, characterized in that: Step 2 uses flatFieldMeta() to recursively parse the properties of the example object into a list of FieldMeta objects, specifically including the following steps: Step 2.1 Call the `flesh()` method to parse the attribute information and encapsulate it into a field metadata class; Step 2.2 Take the metadata class returned by the flesh() method as the parent metadata class and call the member() method to parse its subfields; Step 2.3 Iterate through the child metadata class returned by the member() method and process the parent and child fields; Step 2.4 returns a list of all leaf node metadata class objects.

3. The method for constructing complex query conditions for distributed file storage databases according to claim 2, characterized in that: Step 2.1 involves calling the `flesh()` method to parse attribute information and encapsulate it into a field metadata class. This includes the following steps: Step 2.1.1 Parse condition type and attribute name: Automatically identify special query suffixes, break down the attribute name into field name + query condition type. If the attribute name has no suffix, the default query method is EQ. Step 2.1.2 Process attribute name conversion: Convert the attribute names into the corresponding field names in the database according to the defined naming convention; Step 2.1.3 Encapsulate into a metadata class: field name equals the decomposed attribute name, field query method equals the condition type, and field value equals the attribute value.

4. The method for constructing complex query conditions for distributed file storage databases according to claim 2, characterized in that: Step 2.2, which involves calling the member() method to parse its subfields, specifically includes the following steps: Step 2.2.1 If the field value of the class is empty, or the field is a leaf node field, then there are no child fields. The method to determine whether it is a leaf node isLeaf() is used. Step 2.2.2 Determine the type of the field value. If it is a key-value pair type, convert each key-value pair into a metadata class object and add it to the subfield list. Step 2.2.3 Determine the type of the field value. If it is an object defined in the code, use reflection to get all the properties of the object and iterate through the object properties.

5. The method for constructing complex query conditions for distributed file storage databases according to claim 2, characterized in that: Step 2.3, which involves processing parent and child fields, specifically includes the following steps: Step 2.3.1 Determine the field name of the child field's metadata class. If the parent field is empty, assign the parent field the field name of the parent metadata class. Step 2.3.2 Assign the field name of the subfield metadata class.

6. The method for constructing complex query conditions for distributed file storage databases according to claim 1, characterized in that: Step 4 involves calling the metadata class to convert the metadata object into the corresponding Criteria object. Specifically, this includes: Step 4.1 The field names of the metadata object correspond to the database field names of the query conditions of the Criteria object; Step 4.2 The field values ​​of the metadata object correspond to the database field values ​​of the query conditions of the Criteria object; Step 4.3 The query methods for metadata objects correspond to the query methods for Criteria object query conditions.

7. The method for constructing complex query conditions for distributed file storage databases according to any one of claims 1 to 6, characterized in that: The construction method is based on a simplified combination of multi-condition queries for distributed file storage databases, and includes the following steps: Step 1: Receive and iterate through the passed array. Each element in the array is a key-value pair. The connection between multiple fields in the same key-value pair is an AND condition, and the connection between multiple key-value pairs is an OR condition. Step 2: Filter key-value pairs with empty values ​​and convert each valid key-value pair into a Criteria object; Step 3: Combine all Criteria objects in a single key-value pair using the andOperator to generate query conditions; Step 4: Combine all AND conditions using orOperator to generate the final query conditions.

8. The method for constructing complex query conditions for distributed file storage databases according to claim 7, characterized in that: The construction method is based on dynamic construction and composite construction, and includes the following steps: Call the dynamic construction method to obtain the returned database query object Criteria1; Call the composite construction method to obtain the returned database query object Criteria2; Create a new query object Criteria3 that combines the results, and call andOperator to combine Criteria1 and Criteria2 into a single query condition.

9. The method for constructing complex query conditions for distributed file storage databases according to claim 8, characterized in that: The construction method uses the CriteriaBuilder utility class to construct the query conditions for the distributed file storage database.

Images