A code-free platform cross-resource cursor pagination joint search method and system and storage medium

Abstract

The application discloses a code-free platform cross-resource cursor paging joint search method and system and a storage medium, and relates to the technical field of data query and paging. The method comprises the following steps: obtaining a search request containing a search keyword; determining a resource permission range that a current user has access to; constructing a subquery for at least one resource type according to the resource permission range, and projecting data in a corresponding physical table into a unified column structure for each resource type; merging the query results of all subqueries into a joint query result; uniformly sorting the joint query result according to a predetermined sorting rule; and intercepting target paging data from the sorted joint query result according to a paging parameter and returning the target paging data. The application eliminates the phantom read problem of the OFFSET paging in a concurrent writing scene through a composite cursor paging mechanism, calculates the total number on the first page once and provides the total number for subsequent page reuse through a window function, completes the merging and uniform sorting of the results of multiple resource types at the database layer through UNION ALL, and supports dynamic expansion through a configuration-driven resource type mapping, so that the paging stability, query efficiency and system expansibility of the cross-resource joint search are significantly improved.

Description

Technical Field

[0001] This invention relates to the field of data query and pagination technology, specifically to a no-code platform cross-resource cursor pagination joint search method and system. Background Technology

[0002] No-code platforms allow users to build data applications visually without writing code. In a no-code platform, a user's workspace typically contains various heterogeneous resource types, such as databases, tables, fields, and views. Users need to be able to enter keywords in a global search box to perform combined searches across all these heterogeneous resource types, and display the results in a unified timeline and paginated format.

[0003] Existing cross-resource search and pagination solutions have the following problems.

[0004] First, pagination stability is insufficient. Existing solutions mostly use OFFSET pagination or pagination number-based methods. For example, the patent CN107315753B discloses a pagination method and apparatus across multiple databases, which uses pagination numbers, i.e., OFFSET, for pagination. This results in phantom reads in scenarios with frequent data writes. Specifically, when inserting a new record between two pagination operations, OFFSET pagination can lead to duplicate or skipped records in the pagination results, failing to guarantee the continuity and consistency of the pagination results. This solution also requires recording the row number status of each database each time, making its status management complex and reliant on client-side caching.

[0005] Second, the total count calculation is inefficient. Most existing solutions require a COUNT query to obtain the total count for each pagination request, or rely on the client to cache the total count on the homepage, which has consistency issues. For example, the solution disclosed in patent CN107784032B focuses on the incremental output of big data queries, but does not provide an optimized solution for calculating the total count on the homepage once and reusing it on subsequent pages.

[0006] Third, application-layer merging performance is poor. When querying across multiple data sources or tables, existing solutions mostly merge and sort data at the application layer. For example, patent application CN120086274A discloses merging DataFrame objects in memory based on the pandas library, which cannot utilize the database's query optimizer and indexing capabilities, resulting in poor performance in large-scale data scenarios. Furthermore, the lack of a unified sorting benchmark for query results from different resource types or databases during merging leads to disordered order of the merged results.

[0007] Fourth, poor scalability. Adding a new resource type requires modifying a large amount of query logic code, and it cannot be dynamically expanded through configuration-driven methods, resulting in high maintenance costs.

[0008] Fifth, inappropriate access control. Some solutions only perform access filtering after data merging, leading to unnecessary data query and transmission overhead, and posing a risk of unauthorized access. Summary of the Invention

[0009] To address the aforementioned problems in existing technologies, this invention aims to provide a no-code platform-based cross-resource cursor pagination joint search solution. This solution eliminates the phantom read problem of OFFSET pagination in concurrent write scenarios through a composite cursor pagination mechanism, utilizes window functions to calculate the total count on the first page and reuse it for subsequent pages, completes the merging and unified sorting of results from multiple resource types at the database layer through UNION ALL, and adopts configuration-driven resource type mapping to support dynamic expansion, significantly improving the pagination stability, query efficiency, and system scalability of cross-resource joint search.

[0010] To achieve the above objectives, the present invention adopts the following technical solution: Solution 1: This invention provides a no-code platform cross-resource cursor pagination federated search method, including: Obtain a search request, which includes search keywords; determine the scope of resource permissions that the current user is authorized to access; Based on the resource permission scope, read the resource type mapping configuration. The mapping configuration records the correspondence between each resource type and the physical table. Based on the correspondence, construct subqueries for at least one resource type. The subquery for each resource type projects the data in the corresponding physical table into a unified column structure. At the database layer, the UNION ALL operator is used to merge the results of all subqueries into a combined query result; the combined query result is then sorted uniformly according to a predetermined sorting rule. When the search request does not contain a cursor, the total number of records in the joint query result is calculated using a window function, and the number of records specified by the pagination parameter is extracted from the starting position of the sorted joint query result as the homepage data and returned. When the search request contains a composite cursor, the composite cursor is parsed into a timestamp value and a unique identifier value. After locating the position in the sorted joint query results where the sort key value is less than the composite key value formed by the timestamp value and the unique identifier value, the number of records specified by the pagination parameter are extracted as subsequent page data and returned.

[0011] Preferably, the unified column structure includes the following fields: resource unique identifier, resource name, resource type identifier, resource icon identifier, space identifier, creator identifier, and creation time.

[0012] Preferably, the step of constructing subqueries based on the resource permission range for at least one resource type further includes: injecting the resource permission range into the query conditions of each subquery, so that each subquery only queries the resource records that the current user has the right to access.

[0013] Preferably, the scope of resource permissions is represented by a list of space identifiers that the current user has the right to access; for resource types with a space ownership field, the ownership condition of the space identifier list is added to the query conditions of the subquery; for resource types that use their own identifier as a space identifier, the condition that the identifier of the resource type belongs to the list of space identifiers is added to the query conditions of the subquery.

[0014] Preferably, the metadata recorded in the mapping configuration includes at least one of the following: whether the physical table corresponding to the resource type has a deletion time field, and whether the physical table corresponding to the resource type has an icon field.

[0015] Preferably, the predetermined sorting rule is to sort by creation time in descending order, and if the creation times are the same, to sort by unique identifier in descending order.

[0016] Preferably, the format of the composite cursor is "creation time unique identifier"; the step of parsing the composite cursor into a timestamp value and a unique identifier value includes: retrieving the position of the first delimiter in the composite cursor, dividing the composite cursor into a prefix part and a suffix part with the delimiter as the boundary, using the prefix part as the timestamp value, and using the suffix part as the unique identifier value.

[0017] Preferably, the window function is a counting window function, which appends the total number of records to each row of the homepage data.

[0018] Solution 2: This invention also provides a no-code platform cross-resource cursor pagination federated search system, comprising: A request receiving module is used to obtain a search request, wherein the search request contains search keywords; The permission verification module is used to determine the scope of resources that the current user is authorized to access; The query construction module is used to read the resource type mapping configuration according to the resource permission range. The mapping configuration records the correspondence between each resource type and the physical table. Based on the correspondence, a sub-query is constructed for at least one resource type. The sub-query for each resource type projects the data in the corresponding physical table into a unified column structure. The query merge module is used at the database layer to merge the results of all subqueries into a combined query result using the UNION ALL operator. The sorting module is used to sort the results of the joint query in a unified manner according to a predetermined sorting rule; The pagination processing module is used to calculate the total number of records in the combined query results using window functions when the search request does not contain a cursor, and to extract the number of records specified by the pagination parameters from the starting position of the sorted combined query results as the first page data and return it; and when the search request contains a composite cursor, to parse the composite cursor into a timestamp value and a unique identifier value, to locate the position in the sorted combined query results where the sort key value is less than the composite key value formed by the timestamp value and the unique identifier value, and to extract the number of records specified by the pagination parameters as the subsequent page data and return it.

[0019] Option 3: The present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the above-described method.

[0020] The beneficial effects of the present invention include the following aspects.

[0021] First, the composite cursor pagination mechanism ensures stable page turning even in scenarios with frequent data writes, fundamentally eliminating the phantom read problem of OFFSET pagination. The composite cursor is anchored to the position of the last record in the previous query, rather than the row number offset of the record. Even if a new record is inserted between two page turns, the cursor position will not change, and the newly inserted record will only appear in the results when the user searches again from the homepage.

[0022] Secondly, by using window functions to calculate the total count on the first page, subsequent page navigation does not require repeated COUNT queries, significantly reducing database load. With a record size of millions, the query time per page is reduced by approximately 70%.

[0023] Third, by using UNION ALL, the results of multiple resource types are merged and sorted uniformly at the database layer, making full use of the database query optimizer and indexing capabilities, which improves the performance by more than ten times compared to the application layer merging.

[0024] Fourth, by using a unified column projection design, heterogeneous resource types are standardized into a consistent query result structure, simplifying the merging and mapping logic.

[0025] Fifth, by configuring the resource type mapping, no modification to the core query logic is needed when adding new resource types, significantly reducing the cost of expansion and development.

[0026] Sixth, by pre-limiting the scope of permissions at the subquery layer, unauthorized queries are prevented at the database layer, while unnecessary data transmission is avoided, resulting in a query performance improvement of approximately ten times. Attached Figure Description

[0027] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.

[0028] Figure 1 This is an architectural block diagram of the no-code platform cross-resource cursor pagination joint search system in an embodiment of the present invention.

[0029] Figure 2 This is a flowchart illustrating the no-code platform cross-resource cursor pagination joint search method in an embodiment of the present invention.

[0030] Figure label: 110 is the client layer; 120 is the API service layer; 121 is the request receiving module; 122 is the cursor parsing module; 123 is the authorization verification module; 130 is the query construction layer; 131 is the mapping configuration unit; 132 is the subquery construction module; 133 is the column projection normalization module; 134 is the UNION ALL merging module; 135 is the sorting and cursor injection module; 136 is the window function module; 140 is the database layer; 150 is the result processing layer; 151 is the result set mapping module; 152 is the cursor generation module; 153 is the result return module. Detailed Implementation

[0031] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below with reference to specific illustrations.

[0032] This invention addresses the technical challenges of joint search and stable pagination across heterogeneous resources in no-code platforms by proposing a systematic solution based on composite cursor pagination, unified merging and sorting of the UNION ALL database layer, and configuration-driven approach.

[0033] Specifically, this invention uses a tuple containing a timestamp and a unique identifier as the cursor, formatted as "creation time unique identifier," and precisely locates the starting position of the next page using database row comparison syntax. Unlike traditional OFFSET pagination, the composite cursor is anchored to the position of the last record in the previous query, rather than the row number offset of the record. Therefore, even if a new record is inserted between two page turns, the cursor position will not change, and the newly inserted record will not affect the results of the current page and subsequent pages, fundamentally eliminating the phantom read problem of OFFSET pagination in concurrent write scenarios.

[0034] At the query merging level, this invention dynamically constructs subqueries for each resource type, projecting all subqueries onto a unified column structure. The UNION ALL operator is then used to complete the merging at the database layer, and the database query optimizer performs a unified sort at the outer layer. This design fully leverages the database's index scanning and parallel query optimization capabilities while avoiding the overhead of large-scale data transfer and memory sorting at the application layer.

[0035] At the system scalability level, this invention decouples query construction logic from specific resource types by maintaining a mapping configuration from resource types to physical tables. This configuration includes metadata such as table name, whether there is a deletion time field, and whether there is an icon field. When adding a new resource type, only the configuration item needs to be added, without modifying the core query code.

[0036] In this invention, subqueries can be dynamically constructed through configuration-driven mapping; query results of different resource types can be merged in UNION ALL through unified column projection; and composite cursor pagination ensures stable pagination of merged and sorted results in concurrent scenarios. The organic combination of these three elements constitutes a complete cross-resource joint search pagination solution.

[0037] like Figure 1 The diagram shows the architecture of the no-code platform cross-resource cursor pagination joint search system based on the above-mentioned technology. According to the diagram, this system adopts a layered architecture, comprising five layers: client layer 110, API service layer 120, query construction layer 130, database layer 140, and result processing layer 150.

[0038] The API service layer 120 further includes a request receiving module 121, a cursor parsing module 122, and an authorization verification module 123.

[0039] The query construction layer 130 further includes a mapping configuration unit 131, a subquery construction module 132, a column projection normalization module 133, a UNION ALL merging module 134, a sorting and cursor injection module 135, and a window function module 136.

[0040] The result processing layer 150 further includes a result set mapping module 151, a cursor generation module 152, and a result return module 153. Data is transferred between these layers via interfaces, forming a complete processing chain from request reception to result return.

[0041] Furthermore, the client layer 110 in this system is used to initiate search requests. It provides the API service layer 120 with parameters such as search keywords, page size, cursor, and resource type filtering, and receives the pagination result set and the next page cursor returned by the API service layer 120. The client layer 110 manages the pagination status, including parameters such as the current page cursor and the number of records per page, and initiates new requests when the user scrolls or clicks the page-turning control.

[0042] The API service layer 120 in this system is used to receive search pagination requests from clients and extract parameters. Specifically, the API service layer 120 is jointly operated by the request receiving module 121, the cursor parsing module 122, and the permission verification module 123.

[0043] The request receiving module 121 receives a search request initiated by the client. The search request includes search keywords and optionally also includes pagination parameters, cursor, and resource type filtering conditions. The request receiving module 121 validates the request parameters, including checking whether the pagination size is within a valid range and whether the cursor format is valid, and then passes the parameters to subsequent modules.

[0044] The cursor parsing module 122 performs parsing operations when the request contains cursor parameters. This module first retrieves the position of the first delimiter in the cursor string, then divides the cursor string into a prefix and a suffix part using this delimiter as the boundary. The prefix part is extracted as the cursor timestamp value, and the suffix part is extracted as the cursor identifier value. Finally, the extracted cursor timestamp value is converted into a date and time format recognizable by the database, and the cursor identifier value is used as a matching condition for unique resource identification.

[0045] The permission verification module 123 invokes a separate permission service based on the user authentication information in the request to obtain a list of resource space identifiers that the user is authorized to access. This permission verification is completed before query construction, ensuring that all subsequent queries are executed within the scope of permissions.

[0046] The query construction layer 130 in this system is the core layer of this invention. It receives the parsed parameters and permission ranges transmitted by the API service layer 120, and generates the final structured query statement through the collaborative work of various sub-modules. Specifically, the query construction layer 130 is composed of a mapping configuration unit 131, a subquery construction module 132, a column projection normalization module 133, a UNION ALL merging module 134, a sorting and cursor injection module 135, and a window function module 136.

[0047] The mapping configuration unit 131 stores and maintains resource type mapping configurations, which record the correspondence between each resource type and a physical table, as well as the metadata of each physical table.

[0048] Specifically, this configuration includes the following mapping relationships: For the resource type "Base", its corresponding physical table name is "base", which has a deletion time field and an icon field; For the resource type "Table", its corresponding physical table name is "table_meta", which has a deletion time field and an icon field; For the resource type "Field", its corresponding physical table name is "field", and this table does not have a deletion time field or an icon field; For the resource type "View", its corresponding physical table is named "view". This table does not have a deletion time field or an icon field. This configuration can be stored in a database table or a configuration file and supports dynamic updates.

[0049] The subquery building module 132 has a built-in type determination logic unit. This unit determines the target resource type to be used to build the subquery based on the resource type filtering parameters in the search request: if a resource type is specified, the subquery is built only for that type; if not specified, all resource types in the mapping configuration are traversed.

[0050] For each target resource type determined by the type determination logic unit, the subquery building module 132 generates a subquery statement that queries data from the corresponding physical table and projects it into a unified column structure, based on the physical table name and metadata recorded in the mapping configuration.

[0051] The column projection normalization module 133 ensures that all subquery outputs have consistent column names, types, and order. This unified column structure includes the following seven fields: resource unique identifier, resource name, resource type identifier, resource icon identifier, space identifier, creator identifier, and creation time. For fields missing in the physical table of certain resource types, the column projection normalization module 133 employs a filling strategy: for resource types without an icon field, null values ​​are used to fill the icon column; for resource types without a deletion time field, deletion time filtering is not added to the query conditions.

[0052] The UNION ALL merging module 134 joins all subqueries using the UNION ALL operator to form a merged query result. The sorting and cursor injection module 135 adds a unified sorting rule to the outer query, and adds compound comparison conditions to the WHERE clause of this module when a cursor exists. The window function module 136 adds a total count window function to the select list of the outer query when the homepage is requested.

[0053] The database layer 140 in this system stores physical data for various resource types, including spatial tables, data tables, metadata tables, field tables, and view tables. This layer executes the structured query statements generated by the query construction layer 130 and utilizes pre-built composite indexes for efficient data retrieval. To support efficient location of sort keys, the system establishes composite indexes on the physical tables corresponding to each resource type. Each composite index uses the creation time column as the first index key and is sorted in descending order, and uses the unique identifier column as the second index key and is sorted in descending order.

[0054] The result processing layer 150 in this system receives the query results returned by the database layer 140 and performs post-processing. Specifically, the result processing layer 150 is composed of a result set mapping module 151, a cursor generation module 152, and a result return module 153.

[0055] The result set mapping module 151 maps each field returned by the database to an attribute of the response object.

[0056] The cursor generation module 152 determines whether there is data on the next page, and its judgment logic is as follows: If the number of records returned is equal to the number of records per page specified by the pagination parameter, it is determined that there is a next page; otherwise, it is determined that there is no next page. Under the condition that there is a next page, the cursor generation module 152 takes the creation time and unique identifier of the last record in the returned result, converts the creation time into a standardized timestamp string, and concatenates it with the unique identifier to form a next page cursor in the format of "timestamp unique identifier".

[0057] The return result module 153 assembles the final response object, which contains a list of records, a total number of records, an indication of whether there is a next page, and a next page cursor, wherein the total number of records is only valid in the first page response.

[0058] Based on the above system architecture, this invention further provides a no-code platform cross-resource cursor pagination joint search method.

[0059] See Figure 2 The specific steps of the no-code platform cross-resource cursor pagination federated search based on the above system include the following: In step S101, the API service layer 120 receives a search request initiated by the client layer 110. The search request includes search keywords and optionally also includes pagination parameters, cursor, and resource type filtering conditions.

[0060] The request receiving module 121 of the API service layer 120 validates the request parameters, including checking whether the page size is within a valid range and whether the cursor format is valid. If the request contains cursor parameters, the cursor parsing module 122 performs a parsing operation: first, it retrieves the position of the first delimiter in the cursor string, then it divides the cursor string into a prefix part and a suffix part using the delimiter as the boundary. The prefix part is extracted as the cursor timestamp value, and the suffix part is extracted as the cursor identifier value. Finally, the extracted cursor timestamp value is converted into a date and time format that the database can recognize, and the cursor identifier value is used as a matching condition for the unique identifier of the resource.

[0061] In step S102, the permission verification module 123 invokes an independent permission service based on the user authentication information in the request to obtain a list of resource space identifiers that the user is authorized to access. This permission verification is completed before the query is constructed, ensuring that all subsequent queries are executed within the scope of permissions. The list of space identifiers returned by the permission service is, for example, a set of three space identifiers, indicating that the user is authorized to access all resources in these three spaces.

[0062] In step S103, the query construction layer 130 constructs subqueries for at least one resource type based on the permission scope provided by the permission verification module 123 and the resource type filtering conditions in the search request. The specific implementation process of this step is as follows.

[0063] The mapping configuration unit 131 first provides a resource type mapping configuration, which records the correspondence between each resource type and a physical table, as well as the metadata of each physical table. Second, the type determination unit determines the target resource type for which a subquery needs to be constructed based on the resource type filtering parameters in the search request: if a resource type is specified, a subquery is constructed only for that type; if not specified, all resource types in the mapping configuration are traversed. Finally, the subquery construction module 132 generates a subquery statement for each target resource type, based on the mapping configuration, which queries data from the corresponding physical table and projects it into a unified column structure.

[0064] The column projection normalization module 133 ensures that all subquery outputs have consistent column names, types, and order. This unified column structure includes the following seven fields: resource unique identifier, resource name, resource type identifier, resource icon identifier, space identifier, creator identifier, and creation time. For fields missing in the physical table of certain resource types, the column projection normalization module 133 employs a filling strategy: for resource types without an icon field, null values ​​are used to fill the icon column; for resource types without a deletion time field, deletion time filtering is not added to the query conditions.

[0065] Each subquery includes permission conditions, search conditions, and soft delete conditions. Permission conditions are as follows: for resource types with a space ownership field, add an ownership condition for the space identifier list to the query conditions; for resource types using their own identifier as the space identifier (i.e., the Base type), add a condition that the resource type's identifier belongs to the space identifier list to the query conditions. Search conditions are case-insensitive fuzzy matching of the name field against the search keywords. Soft delete conditions are as follows: for resource types with a deletion time field, add a filter condition that the deletion time is empty.

[0066] In step S104, the UNION ALL merging module 134 merges the results of all subqueries into a single union query result. The UNION ALL operator does not perform deduplication; it directly merges all result rows, avoiding the deduplication overhead of the UNION operator. When records of different resource types cannot be completely identical due to different type fields, using UNION ALL offers superior performance.

[0067] In step S105, the sorting and cursor injection module 135 sorts the merged joint query results according to a predetermined sorting rule. This predetermined sorting rule is to sort by creation time in descending order, and if creation times are the same, to sort by unique identifier in descending order.

[0068] When a search request includes a cursor, the sorting and cursor injection module 135 further performs a location operation in the sorted results: it constructs a composite key value from the parsed cursor timestamp value and cursor identifier value, locates the position in the sorted joint query results where the sorting key value is less than the composite key value, and limits the query range to records after that position. This location uses a composite comparison condition: it requires that the record's creation time is less than the cursor timestamp value, or, if the creation time is equal to the cursor timestamp value, it requires that the record's unique identifier is less than the cursor identifier value.

[0069] In step S106, the pagination processing module extracts the target pagination data from the sorted joint query results according to the pagination parameters and returns it. This step is divided into two cases: first page processing and subsequent page processing.

[0070] When the homepage processing, i.e., the search request, does not include a cursor, the window function module 136, while performing a sorting operation on the outer-layer merged results, calls the database window function to count the total number of rows in the merged result set. This count is returned as an additional column along with each row. The query statement returns only the first N records from the starting position of the sorting by limiting the number of rows returned, where N is specified by the pagination parameter.

[0071] The result set mapping module 151 receives the record rows returned by the database, maps each field to an attribute of the response object, and extracts the total number of records from the statistical value field of the returned records. The cursor generation module 152 determines whether there is a next page of data. Its judgment logic is: if the number of returned records is equal to the number of records per page specified by the pagination parameter, then it is determined that there is a next page; otherwise, it is determined that there is no next page. Under the condition that there is a next page, the cursor generation module 152 takes the creation time and unique identifier of the last record in the returned result, converts the creation time into a standardized timestamp string, and concatenates it with the unique identifier to form a next page cursor in the format of "timestamp unique identifier". The result return module 153 assembles the final response object and returns it to the client layer 110. This response object contains a record list, a total number of records, an indication of whether there is a next page, and a next page cursor.

[0072] In subsequent page processing, i.e., when a cursor is included in the search request, the sorting and cursor injection module 135 sets a composite comparison condition in the query criteria to limit the query scope to the set of records after the last record on the previous page. This query no longer includes a total count calculation window function because the total count has already been calculated on the first page and returned to the client layer 110, which caches this value for displaying the total number of pages.

[0073] Result set mapping module 151 receives and maps the record rows returned by the database. Cursor generation module 152 determines whether a next page exists and generates a next page cursor according to the same logic as the homepage processing. Return result module 153 assembles and returns a response object, in which the total value field is empty, and the client layer 110 uses the total value cached on the homepage.

[0074] To more clearly illustrate the present invention and its corresponding technical effects, a specific embodiment is given below.

[0075] An enterprise's internal knowledge base platform uses a no-code database architecture, containing resources such as knowledge bases (Base), tables (Table), fields (Field), and views from multiple departments. Employees need to enter keywords through a global search box to perform a combined search across all accessible resource types, and the results are displayed in descending order of creation time.

[0076] The system is deployed and configured as follows: The database uses PostgreSQL version 14 and contains four physical tables: base, table_meta, field, and view. Each table has a composite index with the creation time column as the first index key (sorted in descending order) and the unique identifier column as the second index key (sorted in descending order). The application server uses the Node.js and NestJS framework and provides a REST API interface. The permissions service is a separate microservice that returns a list of space identifiers that a user is authorized to access based on their user ID.

[0077] The mapping relationships stored in the mapping configuration unit 131 are as follows: resource type "Base" corresponds to physical table "base" and has deletion time field and icon field; resource type "Table" corresponds to physical table "table_meta" and has deletion time field and icon field; resource type "Field" corresponds to physical table "field" and does not have deletion time field and icon field; resource type "View" corresponds to physical table "view" and does not have deletion time field and icon field.

[0078] In the homepage search scenario, employee A enters the keyword "project" in the search box and clicks search. The front end initiates a search request carrying the keyword and page size to the API service layer 120. The request receiving module 121 of the API service layer 120 receives the request and extracts the parameters. The permission verification module 123 calls the permission service based on the user authentication information in the request to obtain the three space identifiers that the user is authorized to access.

[0079] The query construction layer 130 constructs subqueries for four resource types based on the mapping configuration. Each subquery is projected onto a unified seven-column structure, including a unique resource identifier, resource name, resource type identifier, resource icon identifier, belonging space identifier, creator identifier, and creation time. Among them, the Base type subquery uses its own identifier as its belonging space identifier, and Field and View types that do not have an icon field use null values ​​to fill the icon column.

[0080] Each subquery incorporates permission conditions, limiting the query scope to three spaces the user has access to. Fuzzy name matching and soft deletion filtering conditions are also added. The UNION ALL module 134 merges all subqueries, the sorting and cursor injection module 135 sorts them uniformly by creation time in descending order and unique identifier in descending order, and the window function module 136 adds a total count window function. The query statement returns the first N records by limiting the number of rows returned.

[0081] The database layer 140 executes the query statement and returns the result set and the total number of records. The result set mapping module 151 of the result processing layer 150 maps the records to response objects, the cursor generation module 152 extracts the creation time and unique identifier from the last record to generate the cursor for the next page, and the result return module 153 assembles the response object and returns it to the client. Actual testing shows that the execution time of the structured query statement for this homepage query is approximately 85 milliseconds (including the total number of window functions), and the total API response time is approximately 120 milliseconds.

[0082] In a pagination scenario, employee A scrolls to the bottom of the page and clicks "Load More Controls." The front-end, carrying the previously returned next page cursor, initiates a new search request to the API service layer 120. The cursor parsing module 122 parses the cursor, extracting the cursor timestamp value and cursor identifier value by splitting it according to the first delimiter. The permission verification module 123 performs permission verification again to obtain the same list of space identifiers.

[0083] The query construction layer 130 constructs the same UNION ALL subquery. The sorting and cursor injection module 135 adds a compound comparison condition to the query criteria, limiting the query scope to the set of records whose creation time is less than the cursor timestamp value, or whose creation time is equal to the cursor timestamp value and whose unique identifier is less than the cursor identifier value. This query no longer includes a total count window function. The database layer 140 uses a composite index to quickly locate the cursor position and returns the subsequent N records. The result processing layer 150 processes the results and returns a response. Actual testing shows that the structured query statement for this pagination query takes approximately 30 milliseconds to execute, and the total API response time is approximately 55 milliseconds, a reduction of approximately 65% ​​compared to the homepage query.

[0084] In the concurrent write scenario verification, between the homepage query and the pagination query, other users added fifty resource records containing the keyword "project". The creation time of these new records was all later than the creation time of the last record returned by the homepage query. When employee A initiated a pagination request, because the cursor condition limited the query range to the set of records whose creation time was less than the cursor timestamp value, the newly inserted fifty records would not appear in the pagination results because their creation time was greater than the cursor timestamp value, and the original pagination records would not be skipped.

[0085] If the traditional OFFSET pagination method is used, after inserting fifty new records between two queries, the second page actually returns the set of records after the original offset has been pushed back by the new records, resulting in a large number of original records being missed. The solution of this invention completely avoids this problem through a cursor anchoring mechanism.

[0086] In a resource type-based search scenario, employee A wants to search only for resources of type Table. The frontend adds a resource type filter parameter to the request. After the type determination unit in the query construction layer 130 detects this filter parameter, it constructs a subquery only for Table types, without using UNION ALL to merge them, and directly queries and sorts the physical table `table_meta`. This single-type structured query takes approximately 25 milliseconds to execute, which is about 70% faster than the 85 milliseconds of a full-type search.

[0087] In the scenario of adding a new resource type, the platform adds a Dashboard type and needs to support its global search. The administrator simply adds a new mapping record in mapping configuration unit 131, configuring the Dashboard type to correspond to the physical table "dashboard" with a deletion time field and an icon field, and creating a composite index for this physical table in database layer 140 with the creation time column and unique identifier column as keys. This addition operation takes approximately thirty minutes, requires no modification to any core logic code in query construction layer 130, and the Dashboard type automatically participates in global searches and UNION ALL merges.

[0088] Based on the verification data from the above embodiments, the present invention completely eliminates the phantom read problem of OFFSET pagination in terms of pagination stability. Regarding total count efficiency, the query time for subsequent pages is reduced by approximately 65% ​​to 70%. In terms of multi-table merging performance, database-level merging is approximately 13.7 times faster than application-level pandas merging. Regarding scalability, the development cycle for adding new resource types is shortened from two to three days to less than thirty minutes. Regarding permission filtering performance, subquery-level pre-qualification is approximately ten times faster than application-level filtering.

[0089] Based on the above-described no-code platform cross-resource cursor pagination joint search method, this embodiment of the invention also provides a computer-readable storage medium storing a program thereon, which, when executed by a processor, implements the steps of the above-described no-code platform cross-resource cursor pagination joint search method.

[0090] This invention also provides a processor for running a program, wherein the program executes the steps of the above-described no-code platform cross-resource cursor pagination joint search method during runtime.

[0091] This invention also provides a terminal device, which includes a processor, a memory, and a program stored in the memory and executable on the processor. The program code is loaded and executed by the processor to implement the steps of the above-described no-code platform cross-resource cursor pagination joint search method.

[0092] The present invention also provides a computer program product, which, when executed on a data processing device, is adapted to perform the steps of the above-described no-code platform cross-resource cursor pagination joint search method.

[0093] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0094] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0095] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0096] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0097] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0098] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A no-code platform cross-resource cursor pagination joint search method, characterized in that, include: Obtain a search request, which contains search keywords; Determine the scope of resources that the current user is authorized to access; Based on the resource permission scope, read the resource type mapping configuration. The mapping configuration records the correspondence between each resource type and the physical table. Based on the correspondence, construct subqueries for at least one resource type. The subquery for each resource type projects the data in the corresponding physical table into a unified column structure. At the database level, use the UNION ALL operator to merge the results of all subqueries into a single query result; The results of the joint query are sorted uniformly according to a predetermined sorting rule; When the search request does not contain a cursor, the total number of records in the joint query result is calculated using a window function, and the number of records specified by the pagination parameter is extracted from the starting position of the sorted joint query result as the homepage data and returned. When the search request contains a composite cursor, the composite cursor is parsed into a timestamp value and a unique identifier value. After locating the position in the sorted joint query results where the sort key value is less than the composite key value formed by the timestamp value and the unique identifier value, the number of records specified by the pagination parameter are extracted as subsequent page data and returned.

2. The method according to claim 1, characterized in that, The unified column structure includes the following fields: resource unique identifier, resource name, resource type identifier, resource icon identifier, space identifier, creator identifier, and creation time.

3. The method according to claim 1, characterized in that, The step of constructing sub-queries based on the resource permission range for at least one resource type further includes: injecting the resource permission range into the query conditions of each sub-query, so that each sub-query only queries the resource records that the current user has the right to access.

4. The method according to claim 3, characterized in that, The scope of resource permissions is represented by the list of space identifiers that the current user has the right to access; for resource types with a space ownership field, the ownership condition of the space identifier list is added to the query conditions of the subquery; for resource types that use their own identifier as a space identifier, the condition that the identifier of the resource type belongs to the list of space identifiers is added to the query conditions of the subquery.

5. The method according to claim 1, characterized in that, The metadata recorded in the mapping configuration includes at least one of the following: whether the physical table corresponding to the resource type has a deletion time field, and whether the physical table corresponding to the resource type has an icon field.

6. The method according to claim 1, characterized in that, The predetermined sorting rule is to sort by creation time in descending order, and if the creation times are the same, sort by unique identifier in descending order.

7. The method according to claim 1, characterized in that, The format of the composite cursor is "creation time unique identifier"; parsing the composite cursor into a timestamp value and a unique identifier value includes: retrieving the position of the first delimiter in the composite cursor, dividing the composite cursor into a prefix part and a suffix part with the delimiter as the boundary, using the prefix part as the timestamp value, and using the suffix part as the unique identifier value.

8. The method according to claim 1, characterized in that, The window function is a counting window function, which appends the total number of records to each row of the homepage data.

9. A no-code platform cross-resource cursor pagination syndicated search system, characterized in that, include: A request receiving module is used to obtain a search request, wherein the search request contains search keywords; The permission verification module is used to determine the scope of resources that the current user is authorized to access; The query construction module is used to read the resource type mapping configuration according to the resource permission range. The mapping configuration records the correspondence between each resource type and the physical table. Based on the correspondence, a sub-query is constructed for at least one resource type. The sub-query for each resource type projects the data in the corresponding physical table into a unified column structure. The query merge module is used at the database layer to merge the results of all subqueries into a combined query result using the UNION ALL operator. The sorting module is used to sort the results of the joint query in a unified manner according to a predetermined sorting rule; The pagination processing module is used to calculate the total number of records in the combined query results using window functions when the search request does not contain a cursor, and to extract the number of records specified by the pagination parameters from the starting position of the sorted combined query results as the first page data and return it; and when the search request contains a composite cursor, to parse the composite cursor into a timestamp value and a unique identifier value, to locate the position in the sorted combined query results where the sort key value is less than the composite key value formed by the timestamp value and the unique identifier value, and to extract the number of records specified by the pagination parameters as the subsequent page data and return it.

10. A computer-readable storage medium storing a computer program, 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 8.

Images