Method and apparatus for accessing associated entity data by a low-code platform

Abstract

The application discloses a low-code platform associated entity data access method and device. The method comprises the following steps: defining an entity association relationship based on entity association requirements and data model specifications; generating and binding a navigation column in combination with entity metadata; completing field selection and navigation configuration through the navigation column and query requirements to obtain a visual query configuration result; converting the visual query configuration result and the entity association relationship into a query definition; constructing a navigation path structure based on the query definition and executing the query by using a differentiated strategy to obtain a flat query result; and converting the flat result and the navigation column into a nested structure to generate structured data, and accessing associated entity data through the structured data. The application realizes low-code complex multi-table association query, guarantees type safety, avoids N+1 query problems, automatically outputs nested structured data, reduces the use threshold of non-technical users, and improves query efficiency and development convenience.

Description

Technical Field

[0001] This application relates to the field of data query technology, and in particular to a method and apparatus for accessing associated entity data on a low-code platform. Background Technology

[0002] With the widespread adoption of low-code development platforms, multi-table join queries have become a core requirement in business system development. Many scenarios require complex business logic processing through the association of entity data (such as data linkage between orders and customers, or departments and employees). However, existing low-code platforms have many limitations in their methods of accessing associated entities, causing inconvenience to users.

[0003] Currently, the mainstream solutions for join queries mainly include three types: manually constructing JOIN relationships, writing SQL statements manually, and constructing relationships in memory after independent queries. While these solutions can meet basic join requirements, they have significant shortcomings: business users without technical backgrounds need to understand the database table structure and manually specify join conditions, resulting in a heavy configuration burden; join configurations are mostly string references, lacking compile-time type checking, errors can only be detected at runtime, and changes to entity structure may cause silent query failures; the ability to visualize multi-level nested joins is weak, making it difficult to intuitively display join paths and automatically detect circular references; query results are mostly flat data, and in one-to-many join scenarios, parent records are duplicated, requiring users to manually convert them to nested structures, increasing the complexity of front-end processing; they also suffer from N+1 query performance issues or data redundancy expansion defects, and some platforms do not even support self-join queries and tree-shaped result output.

[0004] Therefore, how to simplify the configuration process for accessing related entities, ensure type security, improve visual configuration capabilities and query performance, and automatically output structured nested data is an urgent problem to be solved. Summary of the Invention

[0005] In view of this, the low-code platform associated entity data access method and apparatus provided in this application embodiment can realize low-code complex multi-table join queries, ensure type safety, avoid N+1 query problems, automatically output nested structured data, reduce the usage threshold for non-technical users, and improve query efficiency and development convenience. The low-code platform associated entity data access method and apparatus provided in this application embodiment is implemented as follows:

[0006] This application provides a method for accessing associated entity data on a low-code platform, including:

[0007] The entity association requirements and data model specifications are processed to define the relationship, resulting in the entity association relationship, which includes the relationship type, source entity information and target entity information.

[0008] The entity association relationship and entity metadata are processed to generate and bind navigation columns to obtain navigation columns. The navigation column generation and binding process includes generating a unique relationship identifier for the entity association relationship and configuring navigation columns for the source entity information and the target entity information respectively, binding the navigation columns with the unique relationship identifier, and adding the bound navigation columns to the entity metadata.

[0009] Based on the query requirements, the navigation columns are selected and the navigation configuration is processed to obtain a visual query configuration result;

[0010] The query definition is obtained by performing query model transformation and identifier construction on the visualization query configuration results and the entity association relationship;

[0011] The navigation path structure is constructed and the differential query execution processing is performed on the relationship between the query definition and the entity to obtain a flat query result;

[0012] The flat query results and the navigation columns are subjected to nested structure transformation to obtain structured data, which is then used to access related entity data.

[0013] In some embodiments, the step of generating and binding navigation columns to the entity association relationships and entity metadata to obtain navigation columns includes:

[0014] The entity association relationship is verified to obtain the parameter verification result;

[0015] The relationship between the parameter verification result and the entity association is processed to generate and persist a relationship record, which includes a unique relationship identifier, relationship type, source entity information and target entity information;

[0016] Navigation column configuration processing is performed on the relationship type, the source entity information, and the entity metadata to obtain the data type corresponding to the source entity navigation column. The data type is then bound to the unique relationship identifier to obtain the source entity navigation column.

[0017] Navigation column configuration processing is performed on the relationship type, the target entity information, and the entity metadata to obtain the data type corresponding to the target entity navigation column. The data type is then bound to the unique relationship identifier to obtain the target entity navigation column.

[0018] The source entity navigation column is added to the field list of the corresponding source entity, and the target entity navigation column is added to the field list of the corresponding target entity to obtain the navigation column.

[0019] In some embodiments, the process of selecting fields and configuring navigation for the navigation columns and query requirements to obtain a visual query configuration result includes:

[0020] The navigation columns and the query requirements are filtered by field selection and navigation type identification to obtain the field selection results.

[0021] The field selection results and the query requirements are processed to configure navigation attributes, resulting in navigation attribute configuration results.

[0022] The relationship records and the query requirements are processed to construct a path, resulting in a nested navigation configuration.

[0023] The field selection results, navigation attribute configuration results, and nested navigation configuration results are integrated to obtain a visual query configuration result.

[0024] In some embodiments, the process of performing query model transformation and identifier construction on the visualization query configuration result and the entity association relationship to obtain the query definition includes:

[0025] The entity identifiers of the visualization query configuration results and the relationship records are extracted to obtain entity-related information.

[0026] The entity-related information and the visualization query configuration results are processed to construct identifiers to obtain physical field identifiers;

[0027] The entity-related information and the visualization query configuration results are processed to construct identifiers to obtain formula field identifiers;

[0028] Navigation conversion processing is performed on the relationship type, the unique relationship identifier, and the visualization query configuration result to obtain the navigation field conversion result;

[0029] The query definition is obtained by integrating and assembling the physical field identifier, the formula field identifier, the navigation field conversion result, and the field filtering rules, grouping aggregation rules, grouping filtering rules, sorting rules, and pagination configuration in the visualization query configuration result.

[0030] In some embodiments, the process of constructing a navigation path structure and performing differentiated query execution on the relationship between the query definition and the entity to obtain a flat query result includes:

[0031] A navigation prefix tree is constructed by performing navigation prefix tree construction on the query definition and the relationship record;

[0032] The navigation prefix tree and the relationship record are separated into navigation nodes to obtain one-to-one navigation nodes and many-to-many navigation nodes. The one-to-one navigation nodes correspond to one-to-one and many-to-one types in the association relationship, and the many-to-many navigation nodes correspond to one-to-many types in the association relationship.

[0033] A main query construction process is performed on the navigation node, the query definition, and the relationship record to obtain the main query result;

[0034] Subquery construction processing is performed on the multiple navigation nodes, the main query result, and the relationship record to obtain multiple related entity data;

[0035] The main query result, the data of the multiple related entities, and the relationship record are merged to obtain a flat query result.

[0036] In some embodiments, the nested structure transformation processing of the flat query results and the navigation columns to obtain structured data includes:

[0037] The flat query results and the navigation columns are subjected to path parsing processing to obtain the matching relationship;

[0038] The flat query results and the matching relationships are nested and integrated to obtain an intermediate structure, which includes one-to-one nesting.

[0039] The intermediate structure and the flat query result are aggregated to obtain a transition structure, which includes an aggregate array.

[0040] The transition structure and the relationship record are associated and verified to obtain structured data.

[0041] In some embodiments, the relationship type includes one-to-one, one-to-many, and many-to-one types.

[0042] This application provides an embodiment of a low-code platform associated entity data access device, comprising:

[0043] The processing module is used to define the relationship between entity association requirements and data model specifications to obtain entity association relationships, which include relationship type, source entity information and target entity information.

[0044] The processing module is further configured to generate and bind navigation columns for the entity association and entity metadata to obtain navigation columns. The navigation column generation and binding process includes generating a unique relationship identifier for the entity association and configuring navigation columns for the source entity information and the target entity information respectively, binding the navigation columns to the unique relationship identifier, and adding the bound navigation columns to the entity metadata.

[0045] The navigation module is used to select fields and configure navigation based on query requirements, and obtain visual query configuration results.

[0046] The processing module is also used to perform query model conversion and identifier construction processing on the visualization query configuration result and the entity association relationship to obtain the query definition;

[0047] The processing module is also used to construct a navigation path structure and perform differentiated query execution processing on the relationship between the query definition and the entity to obtain a flat query result;

[0048] The access module is used to perform nested structure transformation processing on the flat query results and the navigation columns to obtain structured data, and to access related entity data through the structured data.

[0049] The computer device provided in this application includes a memory and a processor. The memory stores a computer program that can run on the processor. When the processor executes the program, it implements the method described in this application.

[0050] The computer-readable storage medium provided in this application embodiment stores a computer program thereon, which, when executed by a processor, implements the method provided in this application embodiment.

[0051] This application provides a method and apparatus for accessing associated entity data on a low-code platform. The method defines entity relationships based on entity association requirements and data model specifications; generates and binds navigation columns using entity metadata; completes field selection and navigation configuration using the navigation columns and query requirements to obtain a visual query configuration result; converts the visual query configuration result and entity association relationship into a query definition; constructs a navigation path structure based on the query definition and executes the query using a differentiated strategy to obtain a flat query result; and converts the flat result and navigation columns into a nested structure to generate structured data, which is then used to access associated entity data. This enables low-code complex multi-table join queries, ensures type safety, avoids the N+1 query problem, automatically outputs nested structured data, lowers the barrier to entry for non-technical users, improves query efficiency and development convenience, and solves the technical problems mentioned in the background art. Attached Figure Description

[0052] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0053] Figure 1 A schematic diagram illustrating the implementation flow of a low-code platform associated entity data access method provided in this application embodiment;

[0054] Figure 2 A schematic diagram illustrating the implementation process of obtaining navigation columns provided in an embodiment of this application;

[0055] Figure 3 This is a schematic diagram of a low-code platform associated entity data access device provided in an embodiment of this application. Detailed Implementation

[0056] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0057] The following description of some technologies involved in the embodiments of this application is provided to aid understanding and should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, some descriptions of well-known functions and structures are omitted in the following description.

[0058] Figure 1 This is a schematic diagram illustrating the implementation flow of a low-code platform associated entity data access method provided in this application embodiment, including steps 101 to 106. Wherein, Figure 1 This is merely one execution order shown in the embodiments of this application and does not represent the only execution order for a method of accessing associated entity data on a low-code platform. Where the final result can be achieved, Figure 1 The steps shown can be performed in parallel or in reverse order.

[0059] Step 101: Define the relationship between entity association requirements and data model specifications to obtain entity association relationships.

[0060] In this embodiment, based on the entity association requirements proposed by the user (such as the association between a customer and an order, or the association between an order and an order item), and in conjunction with the general data model specifications of the low-code platform, relationship definition processing is performed. First, the source entity and target entity involved in the association are identified, and the relationship type between them is determined (supporting one-to-one, one-to-many, and many-to-one types). At the same time, source entity information (including entity ID, association field ID, and navigation attribute name) and target entity information (including entity ID, association field ID, and navigation attribute name) are collected.

[0061] During the relationship definition process, the compliance of association requirements is automatically verified. This includes checking the completeness of required information for the source entity, target entity, and associated fields; verifying data type matching of associated fields (e.g., numeric IDs and string IDs cannot be associated); detecting circular dependencies (e.g., entity A associating with entity B, and entity B directly associating with entity A); and ensuring that navigation attribute names are unique within their respective entities. Once verification is successful, an entity association relationship containing the relationship type, source entity information, and target entity information is formed, providing the foundation for subsequent navigation column generation.

[0062] Step 102: Generate and bind navigation columns for entity relationships and entity metadata to obtain navigation columns.

[0063] In this embodiment, navigation column generation and binding are performed based on entity relationships and entity metadata (including entity field structure, data type constraints, etc.) stored on the platform. This results in a pair of navigation columns corresponding to the entity relationship, belonging to the source entity and the target entity respectively. It should be noted that a single entity can generate multiple different navigation columns based on multiple different entity relationships. All navigation columns are included in the entity's field list and can all serve as configuration entry points for related queries, participating in subsequent related query processes.

[0064] Assign a unique relationship identifier to the current entity association, create a relationship record containing the unique relationship identifier, relationship type, source entity information, and target entity information, and persist it to the platform metadata database for easy subsequent querying and verification.

[0065] The data type of the source entity navigation column is determined based on the relationship type. For one-to-many relationships, the data type is set to a collection type (List<target entity type>); for one-to-one or many-to-one relationships, the data type is set to a single entity type (target entity type). Simultaneously, the navigation column type is marked as navigation type and bound to a unique relationship identifier to ensure accurate mapping between the navigation column and the entity association.

[0066] Similarly, the data type of the target entity navigation column is determined based on the relationship type. If it is a many-to-one relationship, the data type is set to a collection type (List<source entity type>); if it is a one-to-one or one-to-many relationship, the data type is set to a single entity type (source entity type). It is also marked as a navigation type and bound with a unique relationship identifier to ensure that it is associated with the same entity relationship as the source entity navigation column, enabling bidirectional access.

[0067] Add the bound source entity navigation column to the source entity's field list, and add the target entity navigation column to the target entity's field list to complete the entity metadata update, making the navigation column an ​​inherent field of the corresponding entity, supporting subsequent query configuration.

[0068] Step 103: Select fields and configure navigation for the navigation columns and query requirements to obtain a visual query configuration result.

[0069] In this embodiment of the application, the visual query editor of the low-code platform performs field selection and navigation configuration processing on all available navigation columns corresponding to the entity based on its own query needs (such as querying order information, including customer details and associated order items).

[0070] The platform's field selector component displays all fields of the main entity being queried (such as an order entity), automatically distinguishing between ordinary physical fields (such as order ID and creation time) and navigation fields (i.e., all navigation columns generated from entity relationships). It also labels each navigation field with the corresponding associated entity information and relationship type for easy user identification. Users can select the desired physical fields and any navigation fields to generate an initial field selection result.

[0071] When a user selects a navigation field, a navigation property configuration dialog box pops up, allowing the user to configure the target query field for the associated entity (such as the name and contact information of the customer entity, or the product name and quantity of the order item entity), set the filtering conditions for the navigation level (such as the order item quantity being greater than 0), sorting rules (such as order items being sorted in descending order by quantity), and grouping and aggregation rules (such as grouping and counting the total number of orders by product type).

[0072] It supports users configuring multi-level nested navigation paths (such as Orders → Customers → Department → Department Manager). During the configuration process, it automatically maintains the set of visited entities and filters entities already included in the navigation path to avoid circular references (such as Orders → Customers → Orders).

[0073] The system integrates the user-selected field list, navigation attribute configuration rules (field selection, filtering, sorting, grouping and aggregation), and multi-level nested navigation paths into a unified visual query configuration result. The visual query configuration result clearly records the core fields, related ranges, navigation rules, and full query operation configuration.

[0074] Step 104: Perform query model transformation and identifier construction on the visualization query configuration results and entity associations to obtain the query definition.

[0075] In this embodiment, the platform front-end compiler receives the visual query configuration result, combines the entity association relationship and the persistent relationship record, performs query model conversion and identifier construction processing, and converts the user-configured visual query model into a back-end executable query definition. The query definition fully covers the general operation capabilities of SQL statements, including field filtering rules, grouping aggregation rules, grouping filtering rules, sorting rules and pagination configuration based on navigation column configuration.

[0076] Parse all entity IDs (including main entity and related entities) from the visualization query configuration results, retrieve persistent relationship records, and obtain metadata such as the mapping of related fields and relationship types between entities to form a set of entity-related information.

[0077] For physical fields in the configuration results, construct physical field identifiers using the table name and column name format (e.g., order.id, customer.name); for formula fields (e.g., total price calculated based on order amount and quantity), construct formula field identifiers using the table name and formula name format (e.g., order.totalPrice); for navigation fields, recursively construct navigation column definitions, determine the navigation type (corresponding to one-to-one or one-to-many relationships), and construct navigation path identifiers using the table name and navigation attribute name format (e.g., order.customer, order.items).

[0078] The navigation column definition is recursively processed to construct the query sub-definition of the target entity. The user-configured hierarchical filtering conditions, sorting rules, and grouping aggregation rules are appended to the corresponding navigation fields to form a complete navigation field transformation result.

[0079] The physical field identifier, formula field identifier, and navigation field conversion results are integrated with the global field filtering rules (Where), grouping configuration (GroupBy), aggregation function configuration (Aggregation), post-grouping filtering rules (Having), global sorting configuration (OrderBy), and pagination configuration in the configuration results. This is then assembled into a complete query definition according to the execution specifications. This definition clarifies the column set, association logic, and full operation rules of the query, and can be directly used for database query execution.

[0080] Step 105 involves constructing a navigation path structure and performing differentiated query execution processing on the query definition and entity association relationship to obtain a flat query result.

[0081] In this embodiment, the query executor receives the above query definition, combines entity associations and relationship records, and performs navigation path structure construction and differentiated query execution processing.

[0082] All navigation paths in the query definition are parsed. The database table corresponding to the main entity is used as the root node. The navigation paths are decomposed hierarchically and inserted into the prefix tree. Each node is marked with its corresponding relationship type, related field mapping relationship and table alias, forming a navigation prefix tree that can efficiently parse related paths.

[0083] Traverse all child nodes of the navigation prefix tree, and based on the relationship type in the relationship record, separate one-to-one navigation nodes and many-to-many navigation nodes. One-to-one navigation nodes correspond to one-to-one and many-to-one types in the association relationship, while many-to-many navigation nodes correspond to one-to-many types in the association relationship.

[0084] For each navigation node, construct the main query SQL: the SELECT clause includes the main entity's physical fields, formula fields, and the target fields for the related entities; the FROM clause specifies the main entity table; the LEFT JOIN clause joins all related entity tables based on the mapping relationship of the related fields; the WHERE, ORDER BY, and LIMIT / OFFSET clauses apply the configured filtering, sorting, and pagination rules, respectively. Execute the main query to obtain the main query result containing the main entity and all related entity data.

[0085] For multiple navigation nodes, extract the list of related key values ​​(such as a list of order IDs) of the main entity from the main query results, and construct a subquery SQL: the SELECT clause contains the target fields of the multiple related entities; the WHERE clause sets the related columns IN (the list of related key values) and the filtering conditions configured in the navigation; the ORDER BY clause applies the corresponding sorting rules. Execute the subquery to obtain the raw data of the multiple related entities, and group it by the related key values ​​to obtain the grouped data of the multiple related entities.

[0086] The main query results are matched and merged with the grouped multi-related entity data according to the association key value. The main entity record will appear repeatedly according to the number of corresponding multi-related entity records, and finally a flat query result is formed that includes the main entity, all one-related entities and the full data of multi-related entities.

[0087] Step 106: Perform nested structure transformation on the flat query results and navigation columns to obtain structured data, and access related entity data through the structured data.

[0088] In this embodiment, based on the flat query results and the navigation metadata (including relationship type, associated fields, navigation path, etc.) corresponding to the navigation columns, a nested structure transformation process is performed to finally obtain structured data that can directly access associated entity data.

[0089] By using the unique relation identifier bound to the navigation column, the navigation metadata in the relation record is retrieved, the association links of each entity data in the flat query results are parsed, and the precise matching relationship between the main entity and the one-to-one related entity, and between the main entity and the many-to-many related entities is clarified.

[0090] Traverse the main entity records in the flat query results, extract the corresponding one-to-one related entity data for each main entity based on the matching relationship, remove duplicates of the main entity data, encapsulate the one-to-one related entity data into sub-objects according to the navigation attribute name, and embed them into the corresponding main entity record to form an intermediate structure containing the core data of the main entity and the one-to-one nested sub-objects.

[0091] Filter all multi-relational entity data from the flat query results, group them by relational key value, aggregate each group of sub-records into an array (maintaining the configured sorting rules), and embed the aggregated array into the corresponding main entity record of the intermediate structure according to the navigation attribute name, forming a transitional structure containing main entity data, one-to-one nested sub-objects, and multi-relational aggregated arrays.

[0092] Based on the transitional structure and relationship records, association validation is performed. This verifies the uniqueness of a single associated sub-object, the accuracy of grouping multiple aggregate arrays, and checks the completeness of all associated entity fields. Upon successful validation, structured data with clearly defined hierarchical relationships is generated. The main entity data serves as the top-level object, embedded as a sub-object for a single associated entity, and as an array for multiple associated entities. Users can directly access associated entity data via `main entity.navigation attribute.field` or `main entity.navigation attribute array[index].field`, enabling convenient access to associated entity data.

[0093] This application's embodiments significantly lower the barrier to entry by implementing low-code complex multi-table join queries. Users are not required to manually configure join conditions, write SQL, or understand database table structures. Through visual configuration and an automatic navigation column generation mechanism, business users without technical backgrounds can complete multi-table join queries simply by selecting fields, solving the problem of heavy manual configuration in existing technologies. Navigation columns are bound to unique relationship identifiers and carry explicit data type information (collective or singleton type), allowing for type validation of join configurations during the design phase. This avoids configuration errors caused by string references and prevents silent failures due to entity structure changes, addressing the lack of type security in existing technologies. Through navigation path structure construction and differentiated query execution strategies, single-type joins (one-to-one, many-to-one) are handled through a main query JOIN, while multiple-type joins (one-to-many) are retrieved through batch subqueries, requiring only 1+M queries (M being the number of many joins). This avoids the result set expansion caused by full JOINs and solves the N+1 query performance problem caused by lazy loading.

[0094] In the above Figure 1 Based on the above, this application embodiment also provides a schematic diagram of the implementation process for obtaining the navigation column, as shown below. Figure 2 As shown, steps 201 to 205 are included:

[0095] Step 201: Validate the entity relationships to obtain the parameter validation results.

[0096] In this embodiment, multi-dimensional parameter verification is performed based on entity relationships to ensure that the relationships are legal and compliant, providing a reliable foundation for the subsequent generation of navigation columns.

[0097] First, check the completeness of required fields for entity relationships, confirming that core information such as source entity ID, target entity ID, associated field ID, and navigation attribute name are not missing. Second, verify the data type matching of associated fields. For example, if the associated field of the source entity is an integer ID, the associated field of the target entity must also be an integer to avoid relationship failure due to data type incompatibility. Next, check for circular dependencies. If a source entity directly or indirectly associates with itself (e.g., entity A → entity B → entity A), it is considered a circular dependency and an adjustment prompt is given. Finally, verify the uniqueness of navigation attribute names, ensuring that the navigation attribute name of the source entity is not repeated in its field list, and that the navigation attribute name of the target entity does not conflict with its other fields. After all verification items pass, a parameter verification result is generated indicating successful verification. If any items fail, the system will return specific error messages, requiring the user to correct the entity relationships and re-verify.

[0098] Step 202: Generate and persist relationship records based on the parameter verification results and entity associations to obtain relationship records. The relationship records include a unique relationship identifier, relationship type, source entity information, and target entity information.

[0099] In this embodiment, based on the verified parameter verification results and combined with the complete information of the entity association, the system performs relationship record generation and persistence processing. First, a globally unique relationship identifier is assigned to the entity association. This unique relationship identifier is used to uniquely associate the navigation column with the entity association, ensuring the accuracy of subsequent queries and verifications.

[0100] Subsequently, the system creates relationship records containing a unique relationship identifier, relationship type (one-to-one / one-to-many / many-to-one), source entity information (source entity ID, associated field ID, navigation attribute name), and target entity information (target entity ID, associated field ID, navigation attribute name). Finally, the relationship records are persistently stored in the low-code platform's metadata database, forming a reusable and traceable relationship archive that supports subsequent navigation column configuration, query execution, and other processes.

[0101] Step 203: Configure the navigation column for the relation type, source entity information and entity metadata to obtain the data type corresponding to the source entity navigation column, and bind the data type with the unique relation identifier to obtain the source entity navigation column.

[0102] In this embodiment, the system performs configuration and binding processing of the source entity navigation column by combining the relationship type in the relationship record, the source entity information, and the entity metadata stored on the platform (including the field structure, data type constraints, field permissions, etc. of the source entity).

[0103] First, determine the data type of the source entity navigation column based on the relationship type. If the relationship type is one-to-many, set the navigation column data type to a collection type (List<target entity type>) to hold multiple target entity data corresponding to one source entity; if the relationship type is one-to-one or many-to-one, set the navigation column data type to a single entity type (target entity type) to hold a single target entity data corresponding to one source entity. Second, mark the navigation column type as Navigation to distinguish it from ordinary physical fields and formula fields, facilitating automatic identification during subsequent query configuration. Finally, bind the configured navigation column to the unique relationship identifier in the relationship record, establishing a strong mapping between the navigation column and the entity association, ensuring that the corresponding association rules can be accurately retrieved through the navigation column, ultimately forming the source entity navigation column.

[0104] Step 204: Configure the navigation column for the relation type, target entity information and entity metadata to obtain the data type corresponding to the target entity navigation column, and bind the data type with the unique relation identifier to obtain the target entity navigation column.

[0105] In this embodiment, referring to the configuration logic of the source entity navigation column, and combining the relationship type, target entity information and entity metadata in the relationship record, the configuration and binding process of the target entity navigation column is performed to ensure that the target entity has the ability to access the source entity in reverse.

[0106] First, the data type of the target entity navigation column is determined based on the relationship type. If the relationship type is many-to-one, the navigation column data type is set to a collection type (List<source entity type>), used to hold data for a single source entity corresponding to multiple target entities. If the relationship type is one-to-one or one-to-many, the navigation column data type is set to a single entity type (source entity type), used to hold data for a single source entity corresponding to one target entity. Then, the navigation column type is also marked as Navigation, and bound to a unique relationship identifier in the relationship record, ensuring that it is associated with the same entity relationship as the source entity navigation column, guaranteeing consistency in bidirectional access. Finally, the target entity navigation column is formed, which, together with the source entity navigation column, constitutes the basis for bidirectional access.

[0107] Step 205: Add the source entity navigation column to the field list of the corresponding source entity, and add the target entity navigation column to the field list of the corresponding target entity to obtain the navigation columns.

[0108] In this embodiment, after configuring and binding the source entity navigation column and the target entity navigation column, the navigation column addition process is performed. The source entity navigation column is added to the field list of the source entity according to the field specifications corresponding to the target entity information, becoming an inherent field of the source entity; at the same time, the target entity navigation column is added to the field list of the target entity according to the field specifications corresponding to the source entity information, becoming an inherent field of the target entity.

[0109] Once added, the navigation columns work in conjunction with other fields of the corresponding entities. The source entity can directly access the target entity's data through the navigation columns, and the target entity can directly access the source entity's data through the navigation columns. Each navigation column is bound to the entity's association relationship through a unique relation identifier, ensuring consistent association logic and accurate data access, ultimately resulting in navigation columns that support bidirectional access.

[0110] This application's embodiments, through multi-dimensional verification of entity relationships, intercept configuration errors at the design stage, avoiding runtime failures caused by invalid relationships in existing technologies and improving system stability. It achieves precise binding and reuse of relationships and navigation columns. Relationship records are persisted and bound with unique relationship identifiers. Navigation columns are strongly associated with relationships through unique relationship identifiers, and navigation columns are automatically updated synchronously when relationships change, solving the problems of disconnection between relationship information and access entry points and poor reusability in existing technologies, ensuring data consistency. It automatically matches the data type (collective or singleton) of the source / target entity navigation columns based on the relationship type, eliminating the need for manual user judgment and configuration, avoiding access anomalies caused by incorrect type settings, and reducing the understanding cost of entity relationship types for non-technical users.

[0111] In some embodiments, field selection and navigation configuration processing are performed on the navigation columns and query requirements to obtain a visual query configuration result, including: field filtering and navigation type identification processing are performed on the navigation columns and query requirements to obtain a field selection result.

[0112] Specifically, based on the navigation columns and the user's specific query needs (such as querying order information and associating it with customer and order item data), field filtering and navigation type identification are performed. A field selector component provides users with a visual field selection interface, allowing them to filter the physical fields they need to query (such as order ID, status, creation time, etc.) from the field list of the main entity (such as the order entity).

[0113] During the field filtering process, navigation columns in the field list are automatically identified. By matching the unique relation identifier bound to the navigation column with its navigation type attribute, ordinary physical fields and navigation fields are distinguished. Simultaneously, persistent relation records are retrieved to obtain basic information about the associated entities corresponding to the navigation fields (such as associated entity name and relation type). The final result is a field selection list containing the selected physical fields, navigation fields, and corresponding basic information about the associated entities.

[0114] Furthermore, the field selection results and query requirements are processed to configure navigation attributes, resulting in navigation attribute configuration results.

[0115] Specifically, for the navigation fields in the field selection results, the system performs navigation attribute configuration processing based on the user's query requirements. When a user selects a navigation field (such as the customersitems navigation column of the order entity), the system automatically pops up a navigation attribute configuration dialog box, providing a dedicated entry point for selecting related entity fields, setting filter conditions, and configuring sorting rules.

[0116] In the dialog box, users can select target query fields (such as customer name and phone number, order item product name and quantity) for related entities (such as customer entity and order item entity). They can also configure filter conditions (such as order item quantity being greater than 0) and sorting rules (such as order items sorted in descending order of quantity) for these navigation fields according to business needs. Based on the relationship records, the system verifies the matching between the configured conditions and the related entity fields to ensure the configuration is legal and valid. Finally, the system provides the navigation attribute configuration result, which includes the specific query fields, filter conditions, and sorting rules for the related entities.

[0117] Furthermore, path construction processing is performed on the relationship records and query requirements to obtain the nested navigation configuration results.

[0118] Specifically, based on persistent relationship records and users' multi-level nested navigation needs (such as order → customer → department → manager), the system performs path construction processing. During path construction, the system automatically maintains a set of visited entities, recording the entities included in the current navigation path.

[0119] When a user configures a multi-level navigation path, the system parses the relationship links between entities using the source entity information, target entity information, and relationship type in the relationship record. Simultaneously, it checks whether the entity to be added already exists in the visited entity set. If it does, it is automatically filtered to avoid circular reference scenarios such as order → customer → order. This process gradually builds a multi-level relationship path that meets business needs and avoids circular references, ultimately resulting in a nested navigation configuration that includes the complete nested navigation path.

[0120] Furthermore, the field selection results, navigation attribute configuration results, and nested navigation configuration results are integrated and processed to obtain the visual query configuration results.

[0121] Specifically, the field selection results, navigation attribute configuration results, and nested navigation configuration results are integrated and processed. Following the query configuration specifications of the low-code platform, core information (including main entity physical fields, navigation fields and related entity query fields, navigation filter conditions, sorting rules, and multi-level nested navigation paths) is structurally assembled to ensure logical consistency and accurate association among various configuration information types.

[0122] After integration, a visual query configuration result containing all query configuration rules is generated. The visual query configuration result not only clearly defines the core fields and related entity ranges of the query, but also includes navigation filtering, sorting, and multi-level path rules. It can be directly used as input data for subsequent query model transformation, providing a complete basis for the generation of executable query definitions in the backend.

[0123] This application's embodiments allow users to intuitively distinguish between ordinary fields and navigation fields through visual field selection and automatic navigation type recognition. Combined with a dedicated configuration entry point, it simplifies the configuration process for related entity queries and reduces operational complexity. It supports configuring field filtering, filtering conditions, and sorting rules for navigation attributes, meeting the precise query needs of related entities and solving the problem of configuring nested navigation filtering and sorting conditions in existing technologies. It automatically constructs multi-level nested navigation paths and maintains a set of visited entities, achieving automatic filtering of circular references without requiring users to manually detect closed-loop associations, supporting deep association queries in complex business scenarios. It integrates multiple configuration results to form a unified visual query configuration result, ensuring consistent query rule logic and providing complete and standardized input for subsequent query model transformation, thus improving the effectiveness of query configuration.

[0124] In some embodiments, query model transformation and identifier construction are performed on the visual query configuration results and entity associations to obtain the query definition, including: extracting entity identifiers from the visual query configuration results and relationship records to obtain entity-related information.

[0125] Specifically, based on the visual query configuration results and persistent relationship records, entity identifier extraction is performed. First, the user-selected main entity identifier, associated entity identifiers, and all entity identifiers involved in multi-level nested navigation are parsed from the visual query configuration results, forming a preliminary entity set. Then, using the unique relationship identifier bound to the navigation columns associated with each entity, the corresponding relationship record is retrieved to obtain metadata such as the relationship type, source entity association fields, and target entity association fields for each relationship. The preliminary entity set is then integrated with the metadata in the relationship records to ultimately obtain entity-related information containing the identifiers, association field information, relationship types, and unique relationship identifiers of all involved entities.

[0126] Furthermore, identifier construction processing is performed on the entity-related information and the visualization query configuration results to obtain physical field identifiers.

[0127] Specifically, by combining entity-related information with physical fields (such as the order entity's id, status, creation time, and other non-navigational, non-formula fields) in the visualization query configuration results, identifier construction is performed. Following the format of table_name.column_name, a unique identifier is constructed using the entity identifier from the entity-related information as the table name and the selected physical field name from the visualization query configuration results as the column name. For example, if the main entity is "order" (entity identifier: order), and the physical fields id and status are selected, the corresponding physical field identifiers are order.id and order.status, respectively; if the associated entity is "customer" (entity identifier: customer), and the physical field name is selected, the identifier is customer.name, ensuring that the backend can accurately locate the corresponding database table and field.

[0128] Furthermore, identifier construction processing is performed on entity-related information and visualization query configuration results to obtain formula field identifiers.

[0129] Specifically, following the construction logic of physical field identifiers, and combining entity-related information with formula fields in the visualization query configuration results (such as the total price field calculated based on order amount and quantity), identifier construction is performed. Following the format of table_name.formula_name, the entity identifier in the entity-related information is used as the table name, and the user-configured formula field name in the visualization query configuration results is used as the formula name to generate formula field identifiers. For example, the formula field totalPrice for the order entity (calculated as amount × quantity) corresponds to the identifier order.totalPrice. The identifier must be distinguishable from the physical field identifier format, while ensuring that the backend can recognize and execute the corresponding formula calculation logic.

[0130] Furthermore, navigation transformation processing is performed on the relationship type, unique relationship identifier, and visual query configuration results to obtain the navigation field transformation results.

[0131] Specifically, navigation transformation is performed based on the relationship type in entity associations, the unique relationship identifier in the relationship records, and the navigation field configuration in the visual query configuration results. First, for each navigation field in the visual query configuration results, the relationship record is retrieved using the unique relationship identifier to determine the corresponding navigation type (ToOne or ToMany). Then, navigation column definitions are recursively constructed: for single-level navigation fields, the query definition of the target entity is constructed, and the corresponding physical field identifier or formula field identifier is associated; for multi-level nested navigation fields (e.g., order → customer → department), each level of nested field is recursively transformed according to a depth-first principle, sequentially constructing the entity query definition and identifier for each level. Simultaneously, the filtering conditions (e.g., order item quantity greater than 0) and sorting rules (e.g., descending order by quantity) set for the navigation fields in the visual query configuration results are appended to the corresponding navigation column definitions, forming a navigation field transformation result that includes the navigation type, target entity query definition, nested field transformation results, and conditional rules. Furthermore, navigation path identifiers are constructed in a dot-separated format, such as single-level navigation order.customer and nested navigation order.customer.department.

[0132] Furthermore, the physical field identifier, formula field identifier, navigation field conversion results, and visual query configuration results are integrated and assembled to obtain the query definition.

[0133] Specifically, the obtained physical field identifiers, formula field identifiers, and navigation field conversion results are integrated and assembled with other configuration information (including global filter conditions, grouping configurations, aggregate function configurations, post-grouping filter conditions, sorting configurations, and pagination configurations) in the visual query configuration results. Following the backend-executable query definition format, the physical field identifiers, formula field identifiers, and navigation field conversion results are categorized into the query column definition list and labeled as physical column definitions and navigation column definitions (recursive structure), respectively. Global filter conditions are converted to Where condition definitions, grouping configurations to GroupBy grouping definitions, aggregate function configurations to Aggregation aggregation definitions, post-grouping filter conditions to Having condition definitions, sorting configurations to OrderBy sorting definitions, and pagination configurations to pagination offset definitions. During the integration of all configuration information, a unique relational identifier must be used to ensure the logical consistency of each entity, field, and association rule, ultimately forming a complete and clearly defined backend-executable query definition.

[0134] This application's embodiments ensure accurate association of entity relationships during query model transformation by extracting entity identifiers and integrating relational metadata, avoiding transformation errors caused by missing entity information. Physical field and formula field identifiers are constructed in a unified format, clearly defining field attribution and ensuring the backend can accurately locate data sources, resolving the issues of ambiguous and confusing field references in existing technologies. Recursive transformation of navigation fields with added filtering and sorting conditions supports accurate transformation of multi-level nested navigation, ensuring the complete transmission of complex relational query logic and improving the integrity of query definitions. Integrating various identifiers and transformation results to form standardized query definitions enables seamless integration from front-end visual configuration to back-end executable queries, ensuring accurate implementation of query logic, while type validation ensures the legality of query definitions.

[0135] In some embodiments, navigation path structure construction and differentiated query execution processing are performed on the query definition and entity association relationship to obtain a flat query result, including: navigation prefix tree construction processing is performed on the query definition and relationship record to obtain a navigation prefix tree.

[0136] Specifically, the platform's backend prefix tree builder receives the query definition and persistent relationship records, performs navigation prefix tree construction processing, and provides an efficient path parsing foundation for subsequent differential query execution.

[0137] First, all navigation paths contained in the query definition are parsed, including single-level navigation paths (e.g., order → customer) and multi-level nested navigation paths (e.g., order → customer → department → manager). The database table corresponding to the main entity specified in the query definition is used as the root node of the navigation prefix tree (e.g., when querying order data, the root node is the order table). Then, according to the hierarchical relationship of the navigation path, each related entity is inserted into the prefix tree as a child node in sequence. For each child node, its corresponding relationship type (one-to-one / one-to-many / many-to-one), the mapping relationship of the associated fields with the parent node (e.g., order.customerId=customer.id), and a unique table alias is assigned (e.g., customer_1_1_0department_2_1_0) to avoid field conflicts when joining multiple tables.

[0138] During the construction process, the system automatically integrates duplicate navigation paths to achieve path deduplication. At the same time, it records core information such as the navigation attribute name and associated field ID of each node, and finally forms a well-structured and efficiently traversable navigation prefix tree. This tree fully maps all the relationships and navigation logic in the query definition.

[0139] The navigation prefix tree and relationship records are separated into navigation nodes to obtain one-to-one navigation nodes and many-to-many navigation nodes. One-to-one navigation nodes correspond to one-to-one and many-to-one types in the association relationship, and many-to-many navigation nodes correspond to one-to-many types in the association relationship.

[0140] Furthermore, based on the constructed navigation prefix tree and combined with persistent relationship records, the system performs navigation node separation processing to clarify the query nodes corresponding to different association types, providing a basis for differentiated execution strategies.

[0141] Specifically, iterate through all non-root nodes of the navigation prefix tree and classify each node according to the relationship type recorded in the relationship record. Nodes with one-to-one and many-to-one relationships are classified as one-to-one navigation nodes, and the associated data of these nodes can be integrated into the main query result through a single JOIN operation; nodes with one-to-many relationships are classified as many-to-many navigation nodes, and the associated data of these nodes needs to be obtained through an independent subquery to avoid data redundancy caused by full JOIN.

[0142] During the separation process, the associated field mapping, table aliases, navigation configuration filtering conditions, and sorting rules of each node are recorded synchronously to ensure that this information can be directly reused when constructing subsequent queries. At the same time, it ensures the consistency of the classification and entity association relationship of one-to-one and one-to-many nodes and avoids classification bias.

[0143] Furthermore, a main query is constructed on the navigation node, query definition, and relation record to obtain the main query result.

[0144] Specifically, by combining a navigation node, query definition, and relational records, the platform's backend SQL generator constructs and executes the main query to obtain the main query result containing the main entity and all related entity data.

[0145] The main query SQL is constructed strictly according to the following rules: The SELECT clause includes the physical fields of the main entity specified in the query definition (e.g., order.id, order.status), formula fields (if any), and all target fields of the associated entities corresponding to a navigation node, with table aliases appended to the field names for distinction; the FROM clause specifies the database table corresponding to the main entity and marks the root node table alias (e.g., orderASo); the LEFTJOIN clause joins all entity tables corresponding to a navigation node in sequence according to the mapping relationship of the associated fields in the relation records (e.g., LEFTJOIN customerAScONo.customerId=c.id); the WHERE clause embeds the filtering conditions in the query definition (e.g., o.status='active'); the ORDER BY clause applies the sorting rules in the query definition (e.g., o.createTimeDESC); the LIMIT / OFFSET clause sets the query range according to the pagination configuration.

[0146] After the SQL is constructed, the system executes the main query, reads data from the database and returns it, resulting in a flat-format main query result containing the main entity and all associated entity data. Each record contains a complete mapping between the main entity fields and the associated entity fields.

[0147] Subqueries are constructed from the navigation nodes, main query results, and relational records to obtain the data of the related entities.

[0148] Furthermore, for multi-way navigation nodes, the platform's backend navigation subquery processor, combining the main query results and relationship records, performs subquery construction and execution to obtain grouped multi-way related entity data.

[0149] Specifically, first, the list of related key values ​​for the main entity is extracted from the main query results. The related key is the field corresponding to the many-to-many association (e.g., order.id). By traversing the main query results, all unique related key values ​​are collected to form a key-value list (e.g., [1,2,3,...]). Then, an independent subquery SQL is constructed for each many-to-many navigation node: the SELECT clause contains the target field of the many-to-many association entity specified in the query definition; the WHERE clause contains two conditions: first, the related column IN (key-value list), ensuring that the subquery only retrieves child records corresponding to the main query results; and second, the filtering conditions set in the navigation configuration (e.g., oi.quantity>0); the ORDER BY clause applies the sorting rules in the navigation configuration (e.g., oi.quantityDESC).

[0150] After the subquery SQL is constructed, the system executes all subqueries in batches to obtain the raw data of multiple related entities. Then, the raw data is grouped according to the association key value (such as orderId), and multiple sub-records corresponding to the same association key are integrated into a set. Finally, the data of multiple related entities grouped by association key is obtained, and each group corresponds one-to-one with the main entity record in the main query result.

[0151] Furthermore, the main query results, multi-related entity data, and relationship records are merged to obtain flat query results.

[0152] Specifically, by combining the main query results with data on multiple related entities and relationship records, the system performs data merging processing to integrate the two types of data into a unified, flat query result.

[0153] The merging process is based on the main query results. It matches the grouped records in the multi-related entity data to the corresponding main entity records according to the association key value: For each main entity record, the corresponding multi-related entity group is found according to its association key value. All the sub-records in the group are merged with the main entity record in turn to form multiple flat records containing main entity fields, one-to-one related entity fields and single multi-related entity fields.

[0154] For example, if the main entity record `order.id=1` corresponds to 3 order item records with many relationships, the merge will generate 3 flat records with `order.id=1` as the primary key. Each record contains the main field of the order, the customer association field, and one order item field. After the merge, a flat query result is obtained, containing the full data of the main entity, all one-to-one related entities, and many-to-many related entities. The flat query result completely retains all query data, and the field mapping is clear, providing complete input for subsequent nested structure transformations.

[0155] This application embodiment constructs a navigation prefix tree to uniformly manage single-level and multi-level nested navigation paths, achieving automatic path deduplication and rapid parsing. This solves the problems of cumbersome and inefficient handling of complex navigation paths in existing technologies, while providing clear path basis for differentiated execution. Navigation nodes are separated into one-to-one (one-to-one, many-to-one) and many-to-many (one-to-many) nodes based on association type, clarifying the query logic for different association types. This avoids the problem of inappropriate query strategies caused by confusion in association types in existing technologies, ensuring accurate matching between execution logic and association type. One-to-one navigation nodes integrate data through the main query LEFTJOIN, obtaining complete data of the main entity and all one-to-one related entities in a single query, avoiding the time consumption of multiple independent queries and avoiding the result set expansion caused by the full JOIN strategy, balancing query efficiency and data simplicity. Many-to-many navigation nodes extract association keys in batches based on the main query results, constructing a single subquery using the IN clause to obtain all many-to-many related data, instead of querying each main record individually. This reduces the number of queries from 1+N×M to 1+M (M being the number of many-to-many associations), significantly improving query efficiency.

[0156] In some embodiments, the flat query results and navigation columns are subjected to nested structure transformation to obtain structured data, including: performing path parsing processing on the flat query results and navigation columns to obtain matching relationships.

[0157] Specifically, based on the flat query results and navigation columns, path parsing processing is performed. First, persistent relationship records are retrieved using the unique relationship identifier bound to the navigation columns to obtain navigation metadata (including relationship type, source entity association fields, target entity association fields, and navigation path identifier). Then, based on the mapping relationships of association fields in the navigation metadata (e.g., the correspondence between the customerId of the order entity and the id of the customer entity), field matching analysis is performed on the main entity data, one-to-one related entity data, and many-to-many related entity data in the flat query results to clarify the association links between each entity data. Finally, a precise matching relationship between the main entity and related entities (including one-to-one and many-to-many types) is obtained.

[0158] Furthermore, the flat query results and matching relationships are nested and integrated to obtain an intermediate structure, which includes one-to-one nesting.

[0159] Specifically, combining the flat query results with the aforementioned matching relationships, a nested integration process is performed, focusing on embedding one-to-one related data. The main entity records in the flat query results are traversed, and the one-to-one related entity data corresponding to each main entity is extracted based on the matching relationships. Duplicate main entity data caused by associations in the flat results are removed. According to the navigation attribute names defined in the navigation metadata, the one-to-one related entity data is encapsulated into sub-objects and embedded into the corresponding main entity records, forming an intermediate structure containing the core data of the main entity and one-to-one nested sub-objects, ensuring clear one-to-one relationships and no data redundancy or duplication.

[0160] Furthermore, the intermediate structure and the flat query results are aggregated to obtain the transition structure, which includes an aggregated array.

[0161] Specifically, for the many-to-many related entity data in the intermediate structure and the flat query results, aggregation processing is performed to generate a transitional structure containing an aggregated array. First, based on the many-to-many relationship fields in the matching relationship (such as the id of the order entity and the orderId of the order item entity), all many-to-many related entity data is filtered from the flat query results and grouped by the relationship field value (such as grouping order item data by orderId). Each group of sub-records is aggregated into an array, maintaining the sorting rules of the sub-records. Then, according to the navigation attribute names corresponding to the navigation columns, the aggregated sub-record array is embedded into the corresponding main entity record in the intermediate structure, forming a transitional structure containing main entity data, one-to-one nested sub-objects, and many-to-many aggregated arrays, clearly defining the hierarchical relationship of the many-to-many relationships.

[0162] Furthermore, the transition structure and relationship records are subjected to association verification processing to obtain structured data.

[0163] Specifically, based on the transition structure and persistent relationship records, association validation is performed to ultimately obtain structured data. Using the unique relationship identifier bound to each navigation field in the transition structure, the corresponding relationship record is retrieved to verify the consistency and legality of the data association: It verifies whether one-to-one related sub-objects conform to the unique correspondence rule, with no duplicates or missing data; it verifies whether the many-to-many aggregate array matches the many-to-many relationship type in the relationship record, and whether the grouping logic is accurate; simultaneously, it checks the completeness of all fields in the related entity data to ensure consistency with the queried fields. After successful validation, structured data with clear hierarchical relationships and a well-organized data structure is formed. The main entity data serves as the top-level object, one-to-one related entity data is embedded as sub-objects, and many-to-many related entity data is embedded as arrays. Users can directly access the related entity data using the methods `main entity.navigation attribute.field` or `main entity.navigation attribute array[index].field`.

[0164] This application's embodiments automatically parse the entity association links of flat results based on navigation metadata, eliminating the need for users to manually match associated data and achieving accurate matching between the main entity and associated entities, thus improving data processing efficiency. It automatically completes the nested integration of one-to-one associated data and the aggregation array transformation of many-to-many associated data, converting flat results into hierarchically structured data, solving the problems of complex result processing and the need for manual nesting transformation in existing technologies. Many-to-many associated data is grouped and aggregated by association key, maintaining the configured sorting rules and ensuring the consistency of the order of sub-records, meeting the data sorting requirements of business scenarios. Based on relationship record verification, the consistency and legality of associated data are ensured, guaranteeing the uniqueness of one-to-one associations, the accuracy of many-to-many grouping, and field integrity, improving the reliability of structured data. Users can directly access associated entity data through attribute navigation, simplifying the data usage process.

[0165] While this application provides the method operation steps as described in the embodiments or flowcharts, more or fewer operation steps may be included based on conventional or non-inventive labor. The order of steps listed in this embodiment is merely one possible execution order among many and does not represent the only execution order. In actual device or client product execution, the methods shown in this embodiment or the accompanying drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment).

[0166] like Figure 3 As shown in the illustration, this application also provides an access device 300 for low-code platform associated entity data. The device includes:

[0167] The processing module 301 is used to define the relationship between entity association requirements and data model specifications to obtain entity association relationships, which include relationship type, source entity information and target entity information.

[0168] The processing module 301 is also used to generate and bind navigation columns for entity associations and entity metadata to obtain navigation columns. The navigation column generation and binding process includes generating a unique relationship identifier for the entity association and configuring navigation columns for the source entity information and the target entity information respectively, binding the navigation columns with the unique relationship identifier, and adding the bound navigation columns to the entity metadata.

[0169] The navigation module 302 is used to select fields in the navigation column and process navigation configuration based on query requirements, so as to obtain a visual query configuration result.

[0170] The processing module 301 is also used to perform query model transformation and identifier construction processing on the visualization query configuration results and entity associations to obtain the query definition.

[0171] The processing module 301 is also used to construct the navigation path structure and perform differentiated query execution processing on the query definition and entity association relationship to obtain flat query results.

[0172] Access module 303 is used to perform nested structure transformation on the flat query results and navigation columns to obtain structured data, and access related entity data through the structured data.

[0173] Some modules in the apparatus described in this application can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, classes, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0174] The apparatus or module described in the above embodiments can be implemented by a computer chip or physical entity, or by a product with a certain function. For ease of description, the above apparatus is described by dividing it into various modules according to their functions. When implementing the embodiments of this application, the functions of each module can be implemented in one or more software and / or hardware. Of course, a module that implements a certain function can also be implemented by combining multiple sub-modules or sub-units.

[0175] The methods, apparatus, or modules described in this application can be implemented in a computer-readable program code manner. The controller can be implemented in any suitable manner, such as a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of a memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code manner, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included within it for implementing various functions can also be considered as structures within the hardware component. Alternatively, the device used to implement various functions can be viewed as either a software module that implements the method or a structure within a hardware component.

[0176] This application also provides an apparatus, the apparatus comprising: a processor; a memory for storing processor-executable instructions; wherein, when the processor executes the executable instructions, it implements the method described in this application.

[0177] This application also provides a non-volatile computer-readable storage medium storing a computer program or instructions thereon, which, when executed, enables the method described in this application embodiment to be implemented.

[0178] Furthermore, in the various embodiments of the present invention, each functional module can be integrated into a processing module, or each module can exist independently, or two or more modules can be integrated into a single module.

[0179] The aforementioned storage media include, but are not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Cache, Hard Disk Drive (HDD), or Memory Card. The memory can be used to store computer program instructions.

[0180] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary hardware. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product, or it can be embodied in the process of data migration. The computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, mobile terminal, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0181] The various embodiments described in this specification are presented in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. All or part of this application can be used in numerous general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, mobile communication terminals, multiprocessor systems, microprocessor-based systems, programmable electronic devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices, etc.

[0182] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of this application.

Claims

1. A method for accessing associated entity data on a low-code platform, characterized in that, include: The entity association requirements and data model specifications are processed to define the relationship, resulting in the entity association relationship, which includes the relationship type, source entity information and target entity information. The entity association relationship and entity metadata are processed to generate and bind navigation columns to obtain navigation columns. The navigation column generation and binding process includes generating a unique relationship identifier for the entity association relationship and configuring navigation columns for the source entity information and the target entity information respectively, binding the navigation columns with the unique relationship identifier, and adding the bound navigation columns to the entity metadata. Based on the query requirements, the navigation columns are selected and the navigation configuration is processed to obtain a visual query configuration result; The query definition is obtained by performing query model transformation and identifier construction on the visualization query configuration results and the entity association relationship; The navigation path structure is constructed and the differential query execution processing is performed on the relationship between the query definition and the entity to obtain a flat query result; The flat query results and the navigation columns are subjected to nested structure transformation to obtain structured data, and the associated entity data is accessed through the structured data; The entity association relationship is verified to obtain the parameter verification result; The relationship between the parameter verification results and the entity association is processed to generate and persist relationship records, resulting in relationship records. The relationship record includes a unique relationship identifier, relationship type, source entity information, and target entity information. The process of constructing a navigation path structure and performing differentiated query execution on the query definition and the entity association relationship yields a flat query result, including: The query definition and the relationship record are processed to construct a navigation prefix tree, resulting in a navigation prefix tree; The navigation prefix tree and the relationship record are separated into navigation nodes to obtain one-to-one navigation nodes and many-to-many navigation nodes. The one-to-one navigation nodes correspond to one-to-one and many-to-one types in the association relationship, and the many-to-many navigation nodes correspond to one-to-many types in the association relationship. A main query construction process is performed on the navigation node, the query definition, and the relationship record to obtain the main query result; Subquery construction processing is performed on the multiple navigation nodes, the main query result, and the relationship record to obtain multiple related entity data; The main query result, the data of the multiple related entities, and the relationship record are merged to obtain a flat query result; The nested structure transformation process of the flat query results and the navigation columns to obtain structured data includes: The flat query results and the navigation columns are processed by path parsing to obtain the matching relationship; The flat query results and the matching relationships are nested and integrated to obtain an intermediate structure, which includes one-to-one nesting. The intermediate structure and the flat query result are aggregated to obtain a transition structure, which includes an aggregate array. The transition structure and the relationship record are associated and verified to obtain structured data.

2. The method according to claim 1, characterized in that, The process of generating and binding navigation columns to the entity associations and entity metadata to obtain navigation columns includes: Navigation column configuration processing is performed on the relationship type, the source entity information, and the entity metadata to obtain the data type corresponding to the source entity navigation column. The data type is then bound to the unique relationship identifier to obtain the source entity navigation column. Navigation column configuration processing is performed on the relationship type, the target entity information, and the entity metadata to obtain the data type corresponding to the target entity navigation column. The data type is then bound to the unique relationship identifier to obtain the target entity navigation column. The source entity navigation column is added to the field list of the corresponding source entity, and the target entity navigation column is added to the field list of the corresponding target entity to obtain the navigation column.

3. The method according to claim 2, characterized in that, The process of selecting fields and configuring navigation based on query requirements to obtain visual query configuration results includes: Based on the query requirements, the navigation columns are filtered and the navigation type is identified to obtain the field selection results. Based on the query requirements, the field selection results are processed to configure navigation attributes, resulting in navigation attribute configuration results. Based on the query requirements, the relationship records are processed to construct paths, resulting in a nested navigation configuration. The field selection results, navigation attribute configuration results, and nested navigation configuration results are integrated to obtain a visual query configuration result.

4. The method according to claim 2, characterized in that, The process of performing query model transformation and identifier construction on the visualization query configuration results and the entity association relationship to obtain the query definition includes: The entity identifiers of the visualization query configuration results and the relationship records are extracted to obtain entity-related information. The entity-related information and the visualization query configuration results are processed to construct identifiers to obtain physical field identifiers; The entity-related information and the visualization query configuration results are processed to construct identifiers to obtain formula field identifiers; Navigation conversion processing is performed on the relationship type, the unique relationship identifier, and the visualization query configuration result to obtain the navigation field conversion result; The query definition is obtained by integrating and assembling the physical field identifier, the formula field identifier, the navigation field conversion result, and the field filtering rules, grouping aggregation rules, grouping filtering rules, sorting rules, and pagination configuration in the visualization query configuration result.

5. The method according to claim 1, characterized in that, The relationship types include one-to-one, one-to-many, and many-to-one.

6. A device for accessing entity data associated with a low-code platform, characterized in that, include: The processing module is used to define the relationship between entity association requirements and data model specifications to obtain entity association relationships, which include relationship type, source entity information and target entity information. The processing module is further configured to generate and bind navigation columns for the entity association and entity metadata to obtain navigation columns. The navigation column generation and binding process includes generating a unique relationship identifier for the entity association and configuring navigation columns for the source entity information and the target entity information respectively, binding the navigation columns to the unique relationship identifier, and adding the bound navigation columns to the entity metadata. The navigation module is used to select fields and configure navigation based on query requirements, and obtain visual query configuration results. The processing module is also used to perform query model conversion and identifier construction processing on the visualization query configuration result and the entity association relationship to obtain the query definition; The processing module is also used to construct a navigation path structure and perform differentiated query execution processing on the relationship between the query definition and the entity to obtain a flat query result; The access module is used to perform nested structure transformation processing on the flat query results and the navigation column to obtain structured data, and to access related entity data through the structured data; The processing module is also used to verify the entity association relationship to obtain parameter verification results; The processing module is also used to generate and persist relationship records between the parameter verification results and the entity association, thereby obtaining relationship records; The relationship record includes a unique relationship identifier, relationship type, source entity information, and target entity information. The processing module is further used to construct a navigation path structure and perform differentiated query execution processing on the query definition and the entity association relationship to obtain a flat query result, wherein: A navigation prefix tree is constructed by performing navigation prefix tree construction on the query definition and the relationship record; The navigation prefix tree and the relationship record are separated into navigation nodes to obtain one-to-one navigation nodes and many-to-many navigation nodes. The one-to-one navigation nodes correspond to one-to-one and many-to-one types in the association relationship, and the many-to-many navigation nodes correspond to one-to-many types in the association relationship. A main query construction process is performed on the navigation node, the query definition, and the relationship record to obtain the main query result; Subquery construction processing is performed on the multiple navigation nodes, the main query result, and the relationship record to obtain multiple related entity data; The main query result, the data of the multiple related entities, and the relationship record are merged to obtain a flat query result; The processing module is further configured to perform nested structure transformation on the flat query results and the navigation columns to obtain structured data, wherein: The flat query results and the navigation columns are subjected to path parsing processing to obtain the matching relationship; The flat query results and the matching relationships are nested and integrated to obtain an intermediate structure, which includes one-to-one nesting. The intermediate structure and the flat query result are aggregated to obtain a transition structure, which includes an aggregate array. The transition structure and the relationship record are associated and verified to obtain structured data.

7. A computer device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 5.

8. 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 method as described in any one of claims 1 to 5.

Images