A view-aware asynchronous bulk population method and system in an intelligent data table and a storage medium

Abstract

The application discloses a kind of intelligent data table based on view perception's asynchronous batch filling method, system and storage medium. The method comprises: obtaining batch filling request containing view context information;According to the view context information, determine target record set from data table;Generate task identification, create asynchronous filling task and submit to task queue;The task identification is returned in response to the request;Through the task queue, task is distributed to executor execution to carry out data filling;Maintain task state set to record task state;When task state changes, push state change event to the client of subscription data table through communication channel. The application realizes accurate batch filling through view context perception, realizes non-blocking execution through asynchronous task queue, realizes state persistence and multi-user collaborative perception through task state set, and improves the efficiency and user experience of data table batch filling.

Description

Technical Field

[0001] This invention relates to the field of data table processing technology, specifically to an asynchronous batch filling method, system, and storage medium based on view awareness in intelligent data tables, which is particularly suitable for scenarios where artificial intelligence models are called to intelligently generate field content in batches in online multidimensional data tables. Background Technology

[0002] As enterprises become increasingly information-driven, online multidimensional data tables have become essential tools for data management and team collaboration. In recent years, the rapid development of artificial intelligence technology has led users to expect to directly utilize AI-powered large language models within data tables to intelligently generate field content. Examples include automatically generating marketing copy based on product descriptions, generating personalized recommendations based on customer information, and automatically categorizing feedback.

[0003] In the prior art, the technical solutions related to this invention are mainly distributed in the following directions: (a) Asynchronous batch processing direction Patent application CN103810238A discloses a scheme that divides Excel data into several data groups. The application system sends export requests to an Excel auxiliary application module via a Webservice interface. The auxiliary module distributes the requests to multiple processors for asynchronous execution. Each processor creates a new Excel file in a specified path and writes data row by row into the database. Finally, the multiple files are concatenated into a complete export file for download. This scheme uses an asynchronous call method, delegating the time-consuming and memory-intensive file generation to the background, avoiding the interface freezing problem caused by synchronous calls. However, this scheme is mainly aimed at Excel export scenarios, does not involve AI field filling, lacks the ability to perceive the user's current view conditions, cannot perform batch processing according to the user's work context, and the task status notification mechanism is unclear.

[0004] (ii) WebSocket real-time push direction Patent application CN112019625A discloses a scheme for real-time message push based on establishing a full-duplex data stream channel using the WebSocket protocol. This scheme sets a topic for specific messages and a type identifier for specific data, extracts a unique client identifier using the type identifier, and establishes a WebSocket channel based on the topic and the client's unique identifier to achieve point-to-point push of specific messages to specific clients. However, this scheme is a general message push framework and is not optimized for task state management in data table scenarios. It does not involve the maintenance of table-level task state sets and multi-user collaborative awareness, and it is not integrated with specific business logic such as view query context and AI batch filling.

[0005] In summary, the existing technologies generally have the following problems: (1) lack the ability to perceive user view conditions, and batch filling cannot be aligned with the user's current view context; (2) using synchronous methods to call AI interfaces causes the interface to freeze, and the HTTP timeout limit cannot support large-scale batch processing; (3) lack an asynchronous task queue architecture, the AI ​​inference task is coupled with the client connection, and the task status is lost when the connection is broken; (4) lack a sound task status management and real-time notification mechanism, and users cannot know the progress of batch processing in real time; (5) lack the ability to perceive multi-user collaboration, and multiple users in the same table cannot perceive the status of each other's filling tasks. Summary of the Invention

[0006] The present invention aims to solve at least one of the problems existing in the prior art, and provides an asynchronous batch filling method, system and storage medium based on view awareness in intelligent data tables, so as to realize accurate perception of view context, asynchronous non-blocking execution of tasks, persistent management and real-time notification of task status, and multi-user collaborative perception during the batch filling of AI fields.

[0007] To achieve the above objectives, the present invention provides the following technical solution: Solution 1: This invention provides an asynchronous batch filling method based on view awareness in an intelligent data table, comprising: Obtain a batch fill request, the request containing view context information; Based on the view context information, the target record set is determined from the data table; Generate a task identifier, create an asynchronous fill task corresponding to the target record set, and submit the asynchronous fill task to the task queue; In response to the batch fill request, return the task identifier; The asynchronous filling task is assigned to at least one executor through the task queue to fill the records in the target record set with data. Maintain a task status set, which is used to record the status of the asynchronous filling task; When the state of the asynchronous populate task changes, a state change event is pushed to the clients subscribed to the data table via the communication channel.

[0008] Solution 2: This invention provides an asynchronous batch fill system based on view awareness in an intelligent data table, comprising: The request receiving module is used to obtain batch fill requests, which contain view context information. The view query module is used to determine the target record set from the data table based on the view context information; The task management module is used to generate task identifiers, create asynchronous fill tasks corresponding to the target record set, submit the asynchronous fill tasks to the task queue, and respond to the batch fill request by returning the task identifiers. The task execution module is used to obtain the asynchronous filling task through the task queue and execute it to fill the records in the target record set with data; The status management module is used to maintain a task status set, which records the status of the asynchronous filling task. The event push module is used to push a status change event to clients subscribed to the data table via a communication channel when the status of the asynchronous population task changes.

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

[0010] Compared with the prior art, the present invention has the following advantages: (1) View context awareness: Batch fill requests carry view context information, and the server accurately locates the target record set based on this information, ensuring that the fill object is completely consistent with what the user sees in the current view, thus solving the problem that the existing technology does not perceive the user's view conditions.

[0011] (2) Asynchronous non-blocking execution: An asynchronous task queue architecture is adopted. Batch filling requests immediately return task identifiers. Data filling is performed asynchronously in the background. Client connections are not blocked, and large-scale batch processing is supported.

[0012] (3) Task status persistence: The server maintains a set of task statuses, persistently records the task execution status and progress, and supports the recovery of the status after the client disconnects and reconnects.

[0013] (4) Real-time status notification: Push task status change events in real time through the communication channel to achieve full observability of the task execution process.

[0014] (5) Multi-user collaborative perception: Through data table subscription and event broadcasting mechanism, all online users of the same data table can perceive the status of any batch filling task initiated by any user in real time, avoiding duplicate operations. Attached Figure Description

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

[0016] Figure 1 A schematic diagram of the overall architecture of the view-aware asynchronous batch filling system in the intelligent data table provided in an embodiment of the present invention; Figure 2This is a flowchart illustrating the asynchronous batch filling method based on view awareness in an intelligent data table provided in an embodiment of the present invention. Detailed Implementation

[0017] 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.

[0018] In existing technologies, batch fill operations typically process records from the entire table or records manually selected by the user, failing to consider the filtering, sorting, and grouping conditions of the user's current view. This invention constructs a view context-aware batch triggering mechanism. By carrying view context information in the batch fill request, the server can accurately locate the set of records to be filled based on the user's current view configuration, ensuring that the fill result is completely consistent with what the user sees in their view. This mechanism fundamentally solves the intelligent batch processing requirement of "filling only what the user sees."

[0019] In existing technologies, the data population process is coupled with the client's HTTP request / response cycle, leading to interface freezes and timeouts. This invention employs an asynchronous task queue architecture, completely decoupling the reception of batch population requests from the execution of data population tasks—a task identifier is returned immediately after the request is received, and the population task is submitted to the task queue for asynchronous processing by a background executor. This architecture allows the client to continue other operations without waiting for population to complete, and also supports multiple executors consuming the task queue in parallel, significantly improving system throughput.

[0020] In existing technologies, task status is typically bound to a single task or connection, lacking aggregated views and multi-user sharing mechanisms. This invention constructs a task status set and a multi-user collaborative awareness mechanism. The task status set is maintained on the server side, recording information such as the processing status, progress, and failure records of each task. Based on this, status change events are pushed to clients subscribed to this data table via a communication channel, achieving multi-user collaborative awareness. Simultaneously, a hybrid status synchronization mechanism of "initial polling + real-time push" is adopted—the client obtains the initial status through polling and updates the status in real time through push events; the combination of these two methods ensures both consistency and real-time performance of the status.

[0021] Accordingly, this invention realizes view awareness, asynchronous execution, state persistence, and real-time notification for batch filling of AI fields in intelligent data tables, thereby effectively solving the technical problems of view non-awareness, synchronous blocking, non-persistent state, lack of real-time notification, and lack of multi-user collaboration in the batch filling of AI fields in online multidimensional data tables in the prior art.

[0022] like Figure 2 The flowchart shown is a view-aware asynchronous batch filling method for an intelligent data table formed by the present invention based on the above scheme.

[0023] Based on the diagram, the asynchronous batch population method based on view awareness in this intelligent data table includes the following steps during implementation: First, step S101 obtains the batch fill request.

[0024] After a user triggers a batch population operation, the client encapsulates the view context information in a request and sends it to the server. The request obtained in this step carries the view context information, which is the only way to obtain the "view context" in the entire process. The completeness and accuracy of this information directly affect the execution effect of all subsequent steps.

[0025] Next, after completing the request acquisition in step S101, step S102 determines the target record set.

[0026] Step S102 receives the view context information from step S101, transforms it into specific database query conditions, and thereby determines the target record set that meets the user's view conditions from the data table.

[0027] Step S103: Create and submit an asynchronous fill task.

[0028] Step S103 receives the target record set determined in step S102, creates an asynchronous filling task with the record set as the processing object, and submits it to the task queue.

[0029] The tasks created in this step form a one-to-one binding relationship with the record set determined in step S102, that is, one task corresponds to one specific target record set. Step S103 is also responsible for generating a task identifier, which is the unique index for subsequent steps S104, S106, and S107 to perform task tracking, status management, and event pushing.

[0030] Step S104: Immediately return to the task identifier.

[0031] After successfully submitting the task to the task queue in step S103, step S104 immediately returns the task identifier generated in step S103 to the client. There is a strict temporal dependency between step S104 and step S103, that is, step S104 must be executed after the enqueue operation is completed in step S103, and must be executed before any data filling is performed, so as to ensure that the client can obtain the task identifier as soon as possible, and achieve complete decoupling between request and execution.

[0032] Step S105: Execute the filling task asynchronously.

[0033] In step S105, the task executor retrieves the task submitted in step S103 through the task queue, and then fills in the target record set corresponding to the task with data one by one.

[0034] Steps S105 and S103 are decoupled in time through a task queue, allowing the enqueue operation in step S103 and the dequeue operation in step S105 to occur at different times. Similarly, steps S105 and S104 are also decoupled; when the response from step S104 is returned, step S105 may not have started executing yet, or it may be in progress, without affecting each other.

[0035] Step S106: Maintain the task status set.

[0036] Step S103 writes the initial state of the task to the task state set when the task is created; step S105 continuously updates the progress information in the task state set during execution; step S107 reads the state data from the task state set when a state change event is pushed. The task state set maintained in step S106 is the sole data source for all state information in the entire process. Steps S103 and S105 both write state data to it, and step S107 reads the state data from it for event pushing.

[0037] Step S107: Push the status change event.

[0038] Step S107 continuously monitors for changes in the task state set maintained in step S106. When step S103 creates a task (state write), step S105 updates progress (state update), or a task is completed / failed (state change) triggers a state change in step S106, step S107 detects these changes and then pushes the state change event to the clients subscribed to the data table through the communication channel.

[0039] In summary, the asynchronous batch filling method presented in this invention forms a complete technical solution with a close logical relationship through the main data flow of "view context → target record set → task object → state set → event push" and the timing transformation of "synchronous request processing → asynchronous task execution".

[0040] Based on an understanding of the overall function and logical coordination of the above seven steps, the following section provides a more detailed explanation of the specific implementation plan for each step from a technical implementation perspective.

[0041] The construction and transmission of batch filling requests in step S101 of this method.

[0042] After the user selects a field to be populated and triggers a batch population operation, the client collects the current view's context information. This view context information includes at least view condition parameters used to limit the range of the recordset to be populated, and may specifically include: View identifier: Used to reference the configuration of a predefined view on the server. The server can obtain the predefined filtering, sorting, and grouping configurations based on this identifier.

[0043] Filtering criteria: JSON structure, supports nested AND / OR logic and comparison operators for various field types (such as equal to, not equal to, contain, greater than, less than, empty, not empty, etc.).

[0044] Sorting rules: Array structure, each element contains a field identifier and sorting direction (ascending / descending).

[0045] Grouping rules: An array structure where each element is a field identifier, used to group records by a specified field.

[0046] Fill modes include "full coverage" mode (filling all records that meet the conditions, overwriting existing content) and "null value priority" mode (filling only records that meet the conditions and whose current field value is empty, retaining existing content).

[0047] The client encapsulates the aforementioned view context information along with the field identifiers to be filled, data table identifiers, and other information into an HTTP request and sends it to the server's batch fill API interface.

[0048] In step S102 of this method, the target record set of the view query engine is determined.

[0049] After receiving a batch population request, the server first parses the view context parameters in the request. If the request contains a view identifier, it reads the predefined filtering, sorting, and grouping configurations for that view from the view configuration store; if the request directly contains parameters such as filtering conditions, sorting rules, and grouping rules, it uses these parameters directly.

[0050] Secondly, based on the parsed view condition parameters, construct a database query statement to retrieve the set of records that meet the conditions from the data table. The query logic needs to be consistent with the display logic of the front-end view—the front-end view applies specific filtering conditions and sorting rules, and the set of records retrieved by the server should be completely consistent with the set of records displayed on the front end.

[0051] Next, a count check is performed on the retrieved target record set. If the number of records exceeds the preset row limit, a portion of the records are truncated and processed, with the "row limit reached" flag indicating whether the count has been exceeded. This mechanism prevents excessively large single task sizes from impacting system performance.

[0052] Finally, the determined target record set is passed to the task creation module.

[0053] In step S103 of this method, the asynchronous filling task is created and enqueued.

[0054] The server generates a globally unique task identifier, which serves as the unique index for this asynchronous population task. A task object is created, containing metadata information such as: task identifier, data table identifier, field identifier, target record identifier list, and task creation time.

[0055] The initial state of the task object is written to the task state collection storage to achieve task state persistence. The task state collection storage can use a relational database or a key-value store, supporting efficient table-based queries and task-based update operations.

[0056] Finally, the task object is submitted to the asynchronous task queue. The task queue can be implemented using a message queue or an in-memory queue, supporting management functions such as first-in-first-out scheduling, task priority, and task retries.

[0057] The method responds immediately in step S104.

[0058] After a task is successfully submitted to the task queue, the server immediately returns an HTTP response to the client, without waiting for any data to be populated before execution. The response body contains a task identifier, which the client can use to query the task status or cancel the task later. Optionally, the response body may also include information such as the total number of rows that meet the view criteria, the number of rows actually processed, and whether the row limit has been reached.

[0059] Upon receiving the response, the client immediately displays the status of the task as submitted in the user interface and grays out the action buttons to prevent duplicate submissions.

[0060] In step S105 of this method, the filling task is executed asynchronously.

[0061] The task queue distributes tasks to idle executors according to a scheduling policy. Each executor is an independent worker process or thread that can process multiple tasks in parallel.

[0062] After acquiring a task, the executor first updates the task's status in the task status set to "processing" and triggers a status change event. Then, the executor iterates through the target record list and performs the following operations on each record: (1) Read the configuration information of the fields to be populated from the configuration storage, including the templates required for data generation, input field references and other parameters.

[0063] (2) Construct a data generation request based on the configuration information and the data in the current record. For example, when calling the AI ​​model for population, extract the corresponding field values ​​from the record based on the prompt word template and the input field reference, replace the placeholders in the prompt word template, and construct the complete prompt word text.

[0064] (3) Call external data processing services (such as AI large language model service) to generate data and obtain the generation results.

[0065] (4) Write the generated result into the corresponding field of the current record in the data table to complete the filling of a single record.

[0066] (5) Update the number of tasks processed in the task status set.

[0067] If a record fails to be processed, the executor records the record's identifier and error information to the failed record list and continues processing the next record, instead of interrupting the entire task.

[0068] Once all records have been processed, the executor updates the status of the task in the task status set to "completed" and records the list of failed records (if any).

[0069] The maintenance of the task state set in step S106 of this method.

[0070] The task status set is the core data structure for achieving task status persistence and multi-user collaborative awareness in this invention. The server maintains the task status set, recording the status information of each task. The data structure of the task status set includes the following fields: table identifier, field identifier, task identifier, task status (e.g., pending, processing, completed, canceled, failed), total number of pending records, number of processed records, list of failed records, error message, task creation time, and task last update time.

[0071] The task status set supports the following operations: updating status by task identifier, querying all tasks by table identifier, and querying specific tasks by both table identifier and field identifier. Each update to the task status set can trigger an event notification mechanism to achieve real-time propagation of status changes.

[0072] Optionally, the server maintains a task status set by data table, that is, the data table identifier is used as the first-level index, and the task status of all fields in the same data table is aggregated under the dimension of the data table, so that any user can obtain a complete task view when querying the data table.

[0073] The real-time push of state change events in step S107 of this method.

[0074] The server listens for changes in the task status set. When a task status changes, the following operations are performed: First, generate corresponding status change events based on the change type. Event types can include: task start event, task completion event, task cancellation event, task failure event, etc.

[0075] Secondly, construct the event message body, which includes: data table identifier, field identifier, task identifier, current status, number of processed records, total number of records, processing progress, list of failed records (if any), error message (if any), etc.

[0076] Finally, the event is pushed to all online clients subscribed to the data table via a communication channel. The WebSocket protocol is preferred for this communication channel, leveraging its full-duplex communication capabilities to enable proactive server-to-client push. Alternatively, other communication methods capable of server-side proactive push can also be used.

[0077] Based on the above configuration, in some embodiments, the present invention further constructs a hybrid mechanism for client state synchronization.

[0078] Specifically, this invention constructs a hybrid state synchronization mechanism of "initial polling + real-time push" to ensure the consistency of task states between the client and the server.

[0079] Initial polling: After the client page loads or the communication connection is re-established, the client actively calls the server's status query interface to obtain the task status set of the current data table, caches this status information locally, and updates the user interface.

[0080] Real-time push updates: The client subscribes to state change events for the data table via a communication channel. When any state change event is received, the client invalidates its local cache, calls the state query interface again to fetch the latest task state set, and updates the user interface. This "event-triggered fetch" method combines the reliability of polling with the real-time performance of push updates.

[0081] Based on the above configuration, in some embodiments, the present invention further constructs a task cancellation mechanism, based on which users can actively cancel tasks during task execution.

[0082] Specifically, the client sends a task cancellation request, and the request body contains the task identifier.

[0083] After receiving the request, the server updates the status of the task in the task status set to "cancelled" and sends a cancellation signal to the task queue to mark the task as cancelled.

[0084] Before processing each record, the executor checks if the task has been canceled. If it has, subsequent processing stops and resources are released. Upon task cancellation, a "task cancellation event" is triggered and pushed to all subscribed users.

[0085] Based on the detailed explanation of the method and process above, this invention further provides an asynchronous batch filling system based on view awareness in an intelligent data table that can implement this method.

[0086] like Figure 1As shown, the view-aware asynchronous batch fill system in the intelligent data table provided by this invention is divided into six layers in terms of functional architecture: client layer 10, API gateway layer 20, business logic layer 30, task queue layer 40, data storage layer 50, and external service layer 60. These six layers are not simply stacked, but rather form a close collaborative relationship through a clear call chain, data flow, and event flow.

[0087] Among them, the client layer 10 in the system is the user interface layer of the entire system, which runs on the user's terminal device (such as a personal computer, smartphone or tablet).

[0088] Client layer 10 is configured to achieve the following four aspects: First, it provides a visual display of data tables and a view configuration interface, enabling users to set view conditions such as filtering, sorting, and grouping. Second, in response to the triggered batch fill operation, collect the current view context information and construct a request to send to the server; Third, receive task status notifications pushed by the server and display them in the interface in real time; Fourth, cache task status sets to support rapid recovery and status comparison updates after disconnection and reconnection.

[0089] This client layer 10 is configured with bidirectional communication, which means it can initiate synchronization requests via the HTTP protocol and maintain a persistent connection with the server via a communication protocol (preferably WebSocket) to receive real-time pushes. It also has local state caching capabilities to reduce unnecessary duplicate queries.

[0090] There is a synchronous request-response channel between the client layer 10 and the HTTP API gateway 21 of the API gateway layer 20, used for submitting batch population requests and querying task status; at the same time, there is a persistent communication channel between the client layer 10 and the communication gateway 22 of the API gateway layer 20, used for subscribing to data table status events and receiving real-time push notifications. These two channels work in parallel without interfering with each other, enabling the client layer 10 to receive push notifications immediately after initiating a request, thus decoupling requests from notifications.

[0091] The local cache of client layer 10 is linked with the push event of communication gateway 22. When a push event is received, client layer 10 invalidates the local cache and triggers a re-fetch to ensure the consistency between cached data and server data.

[0092] The API gateway layer 20 in the system is the entry gateway for the entire system, and is responsible for request routing, protocol adaptation and connection management.

[0093] Specifically, the API gateway layer 20 contains two complementary sub-components: the HTTP API gateway 21 and the communication gateway 22.

[0094] HTTP API Gateway 21 provides a RESTful API interface based on the HTTP / HTTPS protocol. It is responsible for receiving various synchronous requests (including batch fill requests, task status query requests, task cancellation requests, etc.) sent by the client layer 10. After performing authentication, rate limiting and parameter verification of the requests, it routes the requests to the corresponding functional modules in the business logic layer 30 for processing and encapsulates the processing results into an HTTP response and returns it to the client layer 10.

[0095] The communication gateway 22 manages the persistent communication connection with the client layer 10 based on the communication protocol (preferably the WebSocket protocol), and is responsible for receiving the client's subscription request (including the data table identifier) ​​and pushing the event messages generated by the business logic layer 30 to all clients that have subscribed to the corresponding data table in real time.

[0096] The HTTP API gateway 21 and the communication gateway 22 share the same data table identification system, ensuring that the data table involved in the request submitted through the HTTP API gateway 21 can be accurately matched with the data table corresponding to the event pushed through the communication gateway 22. This ensures the semantic consistency of request processing and event pushing in terms of data table dimensions.

[0097] The API gateway layer 20 can separate synchronous request processing and asynchronous message push into two independent gateways, avoiding the resource contention and complexity issues caused by a single gateway having to handle both short connection requests and maintain long connection pushes.

[0098] In this system, the business logic layer 30 is the core of the entire system's decision-making and scheduling, undertaking a series of core responsibilities such as request parsing, view querying, task management, task execution scheduling, status maintenance, and event triggering.

[0099] The business logic layer 30 contains eight functional modules: request receiving module 31, view query module 32, task management module 33, task execution module 34, status management module 35, event push module 36, status query module 37, and task cancellation module 38. These eight modules work together through call chains and data flow to form a complete business processing loop.

[0100] Among them, the request receiving module 31 is the entry point of the business logic layer 30. It is configured to receive batch fill requests from the HTTP API gateway 21, parse the view context parameters, data table identifiers and field identifiers in the request body, and pass the view context parameters to the view query module 32 after performing parameter validity verification.

[0101] After being invoked by the request receiving module 31, the view query module 32 is configured to initiate a query to the data storage layer 50 based on the received view context information, determine the target record set that meets the user's view conditions, and return the query results to the request receiving module 31. The request receiving module 31 then passes the target record set to the task management module 33—this call chain of "request receiving module 31 → view query module 32 → request receiving module 31 → task management module 33" ensures the decoupling of the view query logic and the task creation logic, allowing the view query module 32 to be reused (e.g., for view preview functionality).

[0102] When querying a target record set, if the request includes a view identifier, the view query module 32 reads the predefined filtering, sorting, and grouping configurations for that view from the view configuration storage. This view configuration storage, as an extended attribute implementation of the field configurations in the data table storage 51, maintains the same transaction context as the data in the data table storage 51, ensuring consistency between the view configuration and the data table structure.

[0103] The task management module 33 is configured to generate a unique task identifier upon receiving the target record set, create a task object containing information such as the task identifier, data table identifier, field identifier, and a list of target record identifiers, and write the initial state of the task object to the task state collection storage 52 of the data storage layer 50 for state persistence. Then, the task object is submitted to the asynchronous task queue 41 of the task queue layer 40. Upon successful task submission, the task management module 33 immediately constructs a response containing the task identifier and returns it to the client layer 10 via the HTTP API gateway 21. This operation ensures that even if a server failure occurs after the response is returned, the task state is persistently stored and can continue execution after recovery.

[0104] The task execution module 34 is configured to implement background asynchronous execution, specifically manifested as one or more independently running worker processes or threads (i.e., executors). The functions implemented by the task execution module 34 include: retrieving tasks from the asynchronous task queue 41; reading field configuration information from the configuration storage 53 of the data storage layer 50; constructing a data generation request based on the configuration information and recorded data; calling the data processing service 61 of the external service layer 60 to generate data; writing the generated results to the data table storage 51 of the data storage layer 50; and updating the processing progress in the task status set storage 52 in real time through the status management module 35. Multiple executors can run in parallel, each independently retrieving tasks from the task queue for consumption, achieving horizontal scaling of processing capacity.

[0105] The status management module 35 is configured to provide other modules with a unified read / write interface to the task status collection storage 52. Specifically, the status management module 35 supports three core operations: updating status by task identifier (used by the task management module 33 to write the initial status, and by the task execution module 34 to update the progress and final status), querying all task statuses by data table identifier (used by the status query module 37), and querying specific task statuses by a combination of data table identifier and field identifier.

[0106] The state management module 35 can proactively trigger an event notification after each state update operation is completed, sending the state change event to the event push module 36. Based on this mechanism, state persistence and event push can be decoupled, so that the state update operation can return without waiting for the event push to complete, ensuring the high response performance of the state management module 35.

[0107] The event push module 36 is configured to listen for state change events generated by the state management module 35, encapsulate the state data transmitted by the state management module 35 into a standard format state change event message, and then push the event message to all client layers 10 that have subscribed to the corresponding data table through the communication gateway 22 of the API gateway layer 20.

[0108] The status query module 37 is configured to receive task status query requests (including data table identifiers) sent by the client layer 10 through the HTTP API gateway 21, directly read all task status information of the data table from the task status collection storage 52 of the data storage layer 50, construct a response, and return it to the client layer 10. The status query module 37 and the event push module 36 together constitute a hybrid status synchronization mechanism of "initial polling + real-time push". In this way, the client layer 10 actively pulls the complete status through the status query module 37 when the page loads or the connection is rebuilt, and passively receives status updates through the event push module 36 during operation. The combination of the two ensures the consistency and real-time performance of the status.

[0109] The task cancellation module 38 is configured to receive a task cancellation request (including a task identifier) ​​sent by the client layer 10 through the HTTP API gateway 21, update the task status in the task status set storage 52 of the data storage layer 50 to "cancelled", and simultaneously send a cancellation signal to the asynchronous task queue 41 of the task queue layer 40. The task cancellation module 38 needs to interact with both the status management module 35 (updating the status) and the asynchronous task queue 41 (sending the cancellation signal) simultaneously—this reflects the special nature of the cancellation operation: it needs to modify the persistent status data and interrupt the queue operations that are in progress or waiting to be performed.

[0110] The task queue layer 40 in the system contains a core component called asynchronous task queue 41, which serves as a buffer and decoupler between the task management module 33 and the task execution module 34. Asynchronous task queue 41 is configured to support management functions such as task enqueueing (executed by the task management module 33), dequeueing (executed by the task execution module 34), task confirmation (removing a task from the queue after processing), task retry (re-enqueuing tasks that fail to be processed), and task cancellation (removing a task from the queue or marking it as canceled).

[0111] The data storage layer 50 in the system contains three independent storage components: data table storage component 51, task status collection storage component 52, and configuration storage component 53.

[0112] The data table storage component 51 is configured to store the metadata, record data, field configuration, and view configuration information of the data table (the view configuration is stored in the data table storage 51 as an extended attribute of the field configuration and maintains the same transaction context as the data table structure), and is accessed by the view query module 32 (reading records and view configuration) and the task execution module 34 (writing the population results).

[0113] The task status collection storage component 52 is configured to store the status information of each task in a data table format, which is accessed by the task management module 33 (writing the initial status), the task execution module 34 (updating the status through the status management module 35), and the status query module 37 (reading the status).

[0114] The configuration storage component 53 is configured to store the data generation configuration information of each field (such as AI model name, prompt word template, input field reference, etc.), which is accessed by the task execution module 34 (read configuration).

[0115] These three storage components are independent of each other and serve different business scenarios. This separation design allows each storage component to choose the optimal storage solution based on its access mode. For example, the task status collection storage component 52, which requires frequent read and write operations and table queries, can use key-value storage (such as Redis) to achieve high performance; the data table storage component 51, which needs to support structured queries, can use a relational database (such as MySQL).

[0116] The external service layer 60 of the system contains a data processing service component 61, which is configured to provide the system with computing capabilities for data generation.

[0117] The data processing service component 61 can be an AI large language model service (such as the GPT series, Claude series, or other large models), which is called by the task execution module 34 via HTTP API or SDK. The data processing service component 61 only has a calling relationship with the task execution module 34—when the task execution module 34 processes records one by one, it sends the constructed data generation request to the data processing service component 61, obtains the generation result, and writes it into the data table storage 51.

[0118] The data processing service component 61 is an external independent service, and its specific implementation does not affect the core architecture of the system of the present invention. This design allows the system to flexibly replace different artificial intelligence model service providers.

[0119] The system components of this invention operate through a clear call chain: the client layer 10 initiates a request, which is routed to the business logic layer 30 via the API gateway layer 20; the business logic layer 30 calls the data storage layer 50 and the task queue layer 40; the task execution module 34 calls the external service layer 60; there is a clear data flow: view context information flows from the client layer 10 to the business logic layer 30; the target record set circulates within the business logic layer 30; and the population result flows from the external service layer 60 through the business logic layer 30 to the data storage layer 50; and there is an efficient event flow: state changes are triggered by the state management module 35 and pushed to the client layer 10 via the event push module 36 and the communication gateway 22. This forms a highly collaborative overall architecture, which together realizes the asynchronous execution and real-time notification of view-aware batch population in the intelligent data table.

[0120] Based on an understanding of the overall functions and logical relationships of each layer of the system, the following section provides a more detailed explanation of the specific structural schemes of each component from a technical implementation perspective.

[0121] In some embodiments of the present invention, the client layer 10 in the system can provide a user interface by loading the front-end code of the smart data table web application (such as HTML, CSS, and JavaScript code developed based on the React or Vue framework). The client layer 10 internally includes the following functional components: The view management component is used to configure and display view conditions for data tables, including filtering conditions (supporting AND / OR logical combinations and various comparison operators), sorting rules (supporting multi-field combined sorting), and grouping rules (supporting aggregation of records by specified fields). The innovation of the view management component lies in its ability to structurally store user-configured view conditions as view context objects and fully pass them to the server when the user triggers batch population, rather than simply applying these conditions at the client-side local rendering level.

[0122] The batch fill operation component is used to trigger batch fill and display the task status. When the user clicks the "Batch Fill" button, this component retrieves the current view context object from the view management component, obtains the currently selected field identifier and data table identifier from the table status, and encapsulates this information into a JSON-formatted HTTP request body, sending it to the server. The innovation of this component lies in that, upon receiving the task identifier returned from the server, it immediately marks the corresponding field as "task in progress" and grays out the operation button to prevent the user from submitting repeatedly. Simultaneously, this component maintains a local task status mapping table to cache the task status information for each field.

[0123] The communication connection management component is used to establish and maintain persistent communication connections with communication gateway 22. This component automatically initiates a communication connection establishment request when the page loads, and sends a subscription message (containing a data table identifier) ​​to communication gateway 22 after successful connection establishment. The innovation of this component lies in its automatic reconnection mechanism—when a connection loss is detected, it automatically attempts to reconnect and resends the subscription request after a successful reconnection, ensuring that status notifications are not permanently lost due to network fluctuations.

[0124] The state cache management component is used to cache the set of task states retrieved from the server. After a page loads or the communication connection is re-established, this component calls the server's state query interface to retrieve the complete set of task states from the current data table and caches it in memory. When a state change event is received via the communication connection, the component invalidates the local cache and triggers a re-fetch. The innovation of this component lies in its use of a "cache-invalidate-re-fetch" model, rather than directly updating the cache based on event messages. This ensures strong consistency between cached data and server-side data, avoiding state inconsistencies caused by lost or out-of-order event messages.

[0125] In some embodiments of the present invention, the API gateway layer 20 in the system includes two sub-components: an HTTP API gateway 21 and a communication gateway 22. These two components can be physically deployed in the same server process or deployed independently.

[0126] HTTP API Gateway 21 provides RESTful API interfaces based on the HTTP / HTTPS protocol, including a batch fill interface (POST / api / batch-fill), a task status query interface (GET / api / task-status / {tableId}), and a task cancellation interface (POST / api / task-cancel). Upon receiving a request, HTTP API Gateway 21 first executes a unified authentication middleware (verifying the validity of the access token carried in the request), then a rate limiting middleware (controlling the request rate based on a token bucket algorithm or sliding window algorithm), followed by a parameter validation middleware (verifying the existence of required fields and the correctness of the data format), and finally routes the valid request to the corresponding functional module in the business logic layer 30. The innovation of HTTP API Gateway 21 lies in its separation of batch fill request reception from business logic processing—the gateway is only responsible for request access and preprocessing, without participating in any business logic decisions. This separation of responsibilities allows the gateway layer to scale horizontally independently to handle high-concurrency requests.

[0127] Communication gateway 22 manages full-duplex communication connections with client layer 10 based on the WebSocket protocol (preferred). Specifically, communication gateway 22 internally maintains a subscription manager, which constructs a many-to-many subscription mapping table using table identifiers as keys and all client connections subscribed to that table as values. When a client sends a subscription message (containing the table identifier), the subscription manager adds the client connection to the subscriber list of the corresponding table; when a client disconnects or sends an unsubscribe message, the subscription manager removes the client connection from the subscriber list.

[0128] In some embodiments of the present invention, the implementation of the request receiving module 31 in the business logic layer 30 of the system includes: receiving batch fill requests from the HTTP API gateway 21, and extracting view context parameters (including view identifier, filter conditions, sorting rules, grouping rules, and fill mode), data table identifier, and field identifier from the request body. The request receiving module 31 uses a JSON Schema validator to perform structural verification on the request body, ensuring that all required fields exist and have correct data types. After successful verification, the request receiving module 31 encapsulates the view context parameters into a view query object and passes it to the view query module 32.

[0129] The view query module 32 is specifically configured to receive the view query object transmitted by the request receiving module 31. First, it determines whether the object contains a view identifier. If it does, it reads the predefined filtering, sorting, and grouping configurations for the view from the view configuration extended attributes of the data table storage 51 (view configuration is stored in the data table storage 51 as an extended attribute of field configuration). If it does not contain a view identifier, it directly uses the filtering conditions, sorting rules, and grouping rule parameters in the view query object. Then, the view query module 32 converts the parsed view conditions into a database query statement (such as the WHERE clause, ORDER BY clause, and GROUP BY clause in an SQL statement), executes the query on the data table storage 51, and obtains the complete set of records that meet the conditions. Before returning the query results, the view query module 32 performs a count check on the set of records: if the total number of records exceeds a preset row limit (e.g., 1000 rows), it only returns the first N records, along with a "whether the limit has been reached" flag.

[0130] The task management module 33 is specifically configured to receive the target record set transmitted by the request receiving module 31. First, it generates a globally unique task identifier (using UUID v4 format to ensure global uniqueness). Then, it creates a task object. The task object's data structure includes the following fields: taskId (task identifier), tableId (data table identifier), fieldId (field identifier), recordsIds (a list of target record identifiers, stored as a JSON array), status (initially set to "pending processing"), totalCount (total number of records), processedCount (initially 0), failedRecords (initially an empty array), createdAt (current timestamp), and updatedAt (current timestamp). The task management module 33 persists the task object to the task status collection storage 52 through the write interface provided by the status management module 35. After successful persistence, the task management module 33 serializes the task object into a message (containing taskId and recordsIds) and publishes it to the asynchronous task queue 41. After a task is successfully enqueued, the task management module 33 constructs a response object containing taskId, totalCount, processedCount (which is 0 at this point), and isLimited (whether the upper limit has been reached), and returns it to the client layer 10 via the HTTP API gateway 21. The task management module 33 ensures that the task status is persistently stored before enqueuing, so that even if the task queue fails or the server restarts immediately after enqueuing, the task status will not be lost. After the system recovers, tasks in the "pending" state can be identified from the task status set and re-enqueued.

[0131] The task execution module 34 is specifically configured to run as one or more executor instances, each of which is an independent worker thread or process. Each executor contains six functional units: The task acquisition unit is responsible for pulling tasks from the asynchronous task queue 41. The task acquisition unit adopts a blocking pull mode—when the queue is empty, the executor thread enters a waiting state to avoid unnecessary polling consuming CPU resources. The task acquisition unit supports batch pulling (pulling multiple tasks at once) to improve processing efficiency.

[0132] The configuration reading unit is responsible for reading the configuration information of the fields to be populated from the configuration storage 53. The configuration information includes at least: a data generation template (such as an AI prompt word template, supporting placeholder syntax) and an input field reference list (used to extract the data required for the template from the records). The configuration reading unit reads the configuration once after each fetch task and caches it locally on the executor for reuse in all record processing for that task, avoiding the storage access overhead added by reading the configuration for each record.

[0133] The request construction unit is responsible for constructing a data generation request based on configuration information and the data in the current record. Specifically, the request construction unit extracts the data generation template and input field reference list from the configuration information, then extracts the field values ​​corresponding to the input field reference list from the current record, replaces the placeholders in the template with these field values, and generates the complete data generation request text. For example, when the template is "Please generate marketing copy based on the following product description:\n{product description}" and the input field reference is "product description", the request construction unit extracts the value of the "product description" field from the record, replaces the "{product description}" placeholder in the template, and generates the complete request text. The template engine in the request construction unit supports various placeholder syntaxes (such as {fieldId}, {{fieldName}}, etc.) and supports nested references (nested attributes of object type fields can be referenced in the template), improving configuration flexibility.

[0134] The data invocation unit is responsible for invoking the data processing service 61 of the external service layer 60. The data invocation unit encapsulates the request text generated by the request construction unit into an HTTP request (or gRPC request), sends it to the API endpoint of the data processing service 61, and sets a timeout (e.g., 30 seconds). If the call succeeds, the data invocation unit obtains the generated result text; if the call fails (e.g., timeout, network error, server error code return), the data invocation unit records the error type and error information. The data invocation unit supports an automatic retry mechanism—for recoverable errors (e.g., timeout, 5xx errors), it automatically retryes up to 3 times, with each retry interval increasing (e.g., 1 second, 2 seconds, 4 seconds).

[0135] The result writing unit is responsible for writing the generated results obtained by the data calling unit into the corresponding field of the current record in data table storage 51. The result writing unit adopts a batch submission mode—after processing each batch of records (e.g., every 10 records), a single write operation is submitted to data table storage 51 to reduce database transaction overhead and network round trips. The result writing unit only writes successfully generated results; it does not perform a write operation if the data calling unit fails.

[0136] The status update unit is responsible for updating the processing progress in the task status set storage 52. The status update unit triggers updates at the following times: after each record is processed, it updates the number of records processed; after processing a batch of records (e.g., every 100 records), it writes the number of records processed to the task status set storage 52 in batches; after all tasks are processed, it updates the final status ("complete" or "failed") and the list of failed records. The status update unit uses a batch update strategy to avoid the performance overhead of writing to storage after each record is processed. After each update, the status update unit triggers an event notification through the status management module 35, enabling the event push module 36 to detect progress changes in real time.

[0137] The task execution module 34 is further configured to adopt a parallel processing architecture, in which multiple executors can simultaneously pull different tasks from the task queue for parallel processing. Furthermore, each executor uses a pipelined approach to process records (i.e., steps such as configuration reading, request construction, data retrieval, and result writing can overlap on different records), which significantly improves processing throughput.

[0138] The state management module 35 is specifically configured to maintain read and write operation interfaces for the task state collection storage 52. Specifically, the state management module 35 provides the following core APIs: `updateTaskStatus(taskId, status, updates)` for updating the status and additional fields of a specific task; `getTasksByTableId(tableId)` for querying all tasks in a given table; and `getTaskByTableIdAndFieldId(tableId, fieldId)` for querying tasks in a specific field of a given table. After each successful update operation, the state management module 35 triggers an event notification—encapsulating the state comparison information before and after the update into an event object and sending it to the event push module 36.

[0139] The event push module 36 is specifically configured to listen for status change events sent by the status management module 35 and encapsulate the event data into a standard format status change event message. The event message format includes the following fields: eventType (event type, such as "taskProcessing", "taskCompleted", "taskCancelled", "taskFailed"), tableId (data table identifier), fieldId (field identifier), taskId (task identifier), status (current status), processedCount (number of processed records), totalCount (total number of records), progress (processing progress, calculated as processedCount / totalCount), failedRecords (list of failed records, only included when the task is completed), and timestamp (event generation timestamp). After encapsulation, the event push module 36 pushes the message to all clients subscribed to the data table via the broadcast interface of the communication gateway 22. The event push module 36 implements differentiated push strategies for different types of events. For high-frequency progress update events (such as those triggered after each record is processed), a debouncing mechanism is used (such as merging updates every 100 milliseconds) to avoid excessively frequent pushes that cause client interface lag and network bandwidth waste. For low-frequency critical events (such as task completion, task cancellation, and task failure), pushes are made immediately to ensure that users can be informed of important status changes in a timely manner.

[0140] The status query module 37 is specifically configured to provide a GET / api / task-status / {tableId} interface to receive status query requests sent by the client layer 10 through the HTTP API gateway 21. The status query module 37 extracts the table identifier from the request path, calls the getTasksByTableId interface of the status management module 35 to obtain the task status set of the table, and then serializes the task status set into JSON format and returns it to the client.

[0141] The task cancellation module 38 is specifically configured to receive POST / api / task-cancel requests, with the request body containing the task identifier. The task cancellation module 38 first calls the updateTaskStatus interface of the status management module 35 to update the task's status to "cancelled". After a successful update, the task cancellation module 38 sends a cancellation signal to the asynchronous task queue 41 (if the task queue supports deleting messages by task identifier, all unprocessed messages for that task are removed from the queue; if the task queue does not support deletion, a "cancellation flag" is sent to the task, enabling the executor to recognize that the task has been cancelled and skip execution when it is retrieved).

[0142] In some embodiments of the present invention, the asynchronous task queue 41 in the task queue layer 40 of the system is specifically configured to be implemented using mature message middleware (such as RabbitMQ, Apache Kafka) or memory queue (such as BullMQ).

[0143] The asynchronous task queue 41 specifically includes: task enqueue (the producer calls the publish or push method to send the task message to the queue), task dequeue (the consumer calls the subscribe or pop method to retrieve the task message from the queue), message acknowledgment (the consumer calls the ack method to notify the queue to delete the message after processing), message retry (if the consumer fails to process the message and the error is recoverable, the message queue will resend the message to another consumer or resend it after a delay), and task cancellation (supports removing messages from the queue by task identifier or marking messages as canceled).

[0144] The asynchronous task queue 41 can work with the task status collection storage 52 to ensure "at least once" processing. That is, after the task execution module 34 pulls the task but before it starts processing, it updates the task status to "processing" and calls a message to confirm after processing is completed. If the executor crashes during processing, the message queue will resubmit the task to other executors. The "processing" status recorded in the task status collection storage 52 helps to identify duplicate processing and avoid data overwriting conflicts.

[0145] In some embodiments of the present invention, the data table storage components 51 in the data storage layer 50 of the system can adopt relational databases (such as MySQL, PostgreSQL) or NoSQL databases (such as MongoDB). The data stored in the data table storage 51 includes: data table metadata (table name, creation time, creator, etc.), field configuration (field name, field type, whether it is an AI field, etc.), record data (the specific values ​​of each field), and view configuration information (predefined view filtering, sorting, and grouping configurations, which are stored in the data table storage 51 as extended attributes of the field configurations and maintain the same transaction context as the data table structure). The data table storage 51 supports structured queries (such as SELECT statements with WHERE conditions, ORDER BY sorting, and GROUP BY grouping) to meet the query requirements of the view query module 32, and also supports updates by primary key (UPDATE …WHERE recordId = …) to meet the result writing requirements of the task execution module 34.

[0146] The task status collection storage component 52 can employ a relational database or key-value store (such as Redis). The data structure stored in Task Status Collection Storage 52 is as follows: a composite primary key or index is used, with table identifier and field identifier as the primary key. Each task includes fields such as taskId, status, totalCount, processedCount, failedRecords (stored in JSON format), errorMsg, createdAt, and updatedAt. Task Status Collection Storage 52 supports precise updates by taskId (UPDATE … WHERE taskId = …), range queries by tableId (SELECT * FROM task_status WHERE tableId = …), and combined queries by tableId and fieldId. The innovation of Task Status Collection Storage 52 lies in its table-based storage structure—all task status records in the same table are stored together. This allows queries for all task statuses by table identifier to be completed with only a single index scan, eliminating the need for aggregation queries across multiple tables or partitions, thus ensuring high performance for status queries.

[0147] The configuration storage component 53 can use a relational database or key-value store to store the data generation configuration information for each field, including data generation templates (such as AI prompt word templates), input field reference lists, model parameters (such as temperature, maximum generation length), etc. The configuration storage component 53 supports precise queries by field identifier (SELECT * FROM field_config WHERE fieldId = …), and the task execution module 34 reads the configuration based on this after each task is fetched.

[0148] In some embodiments of the present invention, the data processing service 61 in the system can be an AI large language model service (such as the OpenAI GPT series, Anthropic Claude series, domestic large models such as Wenxin Yiyan or Tongyi Qianwen, etc.), which is called by the task execution module 34 through a standard HTTP RESTful API or SDK. The data processing service 61 receives the data generation request (including prompt text and model parameters) sent by the task execution module 34, performs inference calculations, and returns the generated result text. As an external independent service, the communication protocol, data format, and authentication method of the data processing service 61 are determined by the specific service provider. The system of the present invention supports the API styles of various service providers through the configuration adapter pattern, so that the system can flexibly switch or use multiple AI model services simultaneously. The call between the data processing service 61 and the task execution module 34 is synchronous and blocking. After sending the request, the task execution module 34 waits for the response to return, but this synchronous waiting occurs in the background asynchronous execution process and does not affect the interactive experience of the client layer 10.

[0149] The following specific application examples will illustrate in detail the application and implementation process of the present invention.

[0150] Example 1: Batch generation of e-commerce product marketing copy An e-commerce company uses the intelligent data table system of this invention to manage a product table containing 10,000 product records. The table includes fields such as product ID, product name, product description, price, inventory, and marketing copy. The marketing department needs to generate marketing copy in batches for all products with "inventory > 0 and price < 500 yuan".

[0151] System composition and deployment: The enterprise has deployed the system of this invention, which includes: a front-end web application, back-end services (including an API gateway 21 and various business logic modules), a task queue 41, data storage (MySQL for storing table data and Redis for storing task status sets), and an AI service 61 (interfacing with the GPT-4 API). The system is configured to process a maximum of 1000 rows in batches and has 5 concurrent executors.

[0152] Processing flow: Marketers open a product spreadsheet in a browser, create a view, and set filter conditions: inventory greater than 0 and price less than 500 yuan, retrieving 3,500 records that meet the conditions.

[0153] Marketers select the "Marketing Copy" field, click the "Batch Fill" button, and choose the fill mode as "Empty Value Priority" (only fill records with empty marketing copy to avoid overwriting manually written copy). The front end collects the view context and sends a POST request to the batch fill API.

[0154] The server-side view query module 32 retrieved 3500 records based on the filtering conditions, of which 2800 had empty marketing copy fields. Since the null value priority mode was selected, 2800 records were actually submitted to task queue 41. The API immediately returned the task identifier.

[0155] After receiving the response, the front-end marks the "Marketing Copy" field as "Processing," displays a progress message "Generating (0 / 2800)," and grays out the button. Simultaneously, it subscribes to the table's status events via a communication connection.

[0156] Task queue 41 distributes tasks to 5 executors for parallel processing. Each executor reads the configuration of the "Marketing Copy" field from configuration store 53.

[0157] The executor processes each record one by one, constructing prompts for each record, calling the GPT-4 API to generate marketing copy, and writing it to the corresponding cell. Every 100 records completed, the executor updates the number of records processed in the task status set storage 52, triggering a progress update event.

[0158] The front end receives progress update events through the communication connection and updates the progress display in real time.

[0159] Approximately 15 minutes later, 2800 records were processed, of which 2750 succeeded and 50 failed due to occasional timeouts in the AI ​​service. The executor updated the task status to "completed," recorded the failures, and triggered a task completion event.

[0160] Upon receiving the task completion event, the front-end clears the "Processing" marker and displays "Generation complete, 2750 successful, 50 failed." The button becomes available again, and the table refreshes to display the newly generated marketing copy. Marketers can click "View Failure Records" to see the 50 failed records and retry accordingly.

[0161] Technical Benefits: Batch processing of 2800 records, which traditionally takes approximately 2 hours per record, is reduced to 15 minutes using asynchronous parallel execution, improving efficiency by 8 times. Marketing personnel can immediately continue other work after initiating batch filling without waiting. All online team members receive real-time status updates via communication connections and can see the "Marketing Copy" field is in the "Generating" state, avoiding duplicate submissions. The 50 failed records have clear error messages, allowing for targeted handling without having to start the entire batch again.

[0162] Example 2: Multi-user collaboration and reconnection scenarios A project management team uses the system of this invention to maintain a table containing 5,000 task records, with fields including task ID, task name, responsible person, status, and risk assessment. Project manager A initiates batch filling of the "risk assessment" field (3,000 records) in the office via Wi-Fi, while project manager B views the same table remotely via mobile network.

[0163] Implementation process: Project Manager A initiates a batch population, the frontend sends a request, the API returns a task identifier, the frontend marks the "Risk Assessment" field as "Processing", and displays "Generating (0 / 3000)".

[0164] The task start event is broadcast via the communication channel. Project Manager B's browser receives the event in real time, and the "Risk Assessment" field on his interface simultaneously displays "Generating (0 / 3000)", and the button is grayed out to prevent B from repeatedly initiating the same task.

[0165] During the task execution, Project Manager B experienced a communication connection loss due to unstable mobile network, and the page displayed "Connection lost, reconnecting...".

[0166] After 30 seconds, the network was restored, and the communication connection was automatically and successfully reconnected. The front end immediately called the status query interface to obtain the task status set of the current data table. It found that the "Risk Assessment" field was still being processed, with 1500 / 3000 already processed. The front end then displayed "Generifying (1500 / 3000)", without requiring the user to manually refresh.

[0167] Project Manager A closed the browser and left due to an impromptu meeting. The task continued to execute on the server side, unaffected by the client connection.

[0168] Approximately 20 minutes later, the task was completed, and the server triggered a task completion event. At this time, Project Manager A was no longer online, but Project Manager B's browser received the event through the communication connection, and the interface displayed "Generation Complete (3000 / 3000)". The table data was refreshed to view the generated risk assessment content.

[0169] After the meeting, Project Manager A reopened the browser to load the table. The front end called the status query interface to get the task status set and found that the "risk assessment" field showed that the task was completed. The latest data was loaded directly without re-initiating the task.

[0170] As can be seen from the above, this invention can be widely applied to various online multidimensional data tables, spreadsheets, data management platforms, and other software products. It is particularly suitable for scenarios requiring the use of AI-powered large language models for batch intelligent generation of field content, such as e-commerce product copywriting generation, customer feedback classification, project management risk assessment, and data analysis report generation. Based on universal Web technologies and data processing service interfaces, this invention possesses excellent compatibility and portability, and can be deployed and implemented on various cloud computing platforms and enterprise internal servers, demonstrating broad industrial application prospects and commercial value.

[0171] Based on the above-mentioned view-aware asynchronous batch fill method in the intelligent data table, this embodiment of the invention also provides a computer-readable storage medium storing a program that, when executed by a processor, implements the steps of the above-mentioned asynchronous batch fill method.

[0172] This invention also provides a processor for running a program, wherein the program executes the steps of the above-described asynchronous batch filling method during runtime.

[0173] 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 asynchronous batch filling method described above.

[0174] 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 asynchronous batch filling method.

[0175] 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.

[0176] 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.

[0177] 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.

[0178] 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.

[0179] 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. An asynchronous batch filling method based on view awareness in an intelligent data table, characterized in that, include: Obtain a batch fill request, the request containing view context information; Based on the view context information, the target record set is determined from the data table; Generate a task identifier, create an asynchronous fill task corresponding to the target record set, and submit the asynchronous fill task to the task queue; In response to the batch fill request, return the task identifier; The asynchronous filling task is assigned to at least one executor through the task queue to fill the records in the target record set with data. Maintain a task status set, which is used to record the status of the asynchronous filling task; When the state of the asynchronous populate task changes, a state change event is pushed to the clients subscribed to the data table via the communication channel.

2. The method according to claim 1, characterized in that, The view context information includes view condition parameters, which are used to limit the range of the record set to be filled; the view context information also includes a fill mode, which includes a first mode and a second mode. The first mode indicates that the fill is performed on all records that meet the view conditions, and the second mode indicates that the fill is performed only on records that meet the view conditions and whose current field value is empty.

3. The method according to claim 1, characterized in that, The maintenance task status set includes: maintaining the task status set by data table as the dimension, wherein the task status set records the correspondence between field identifiers and task status; the task status includes at least one of pending status, in-process status, and completed status.

4. The method according to claim 1, characterized in that, The communication channel is a WebSocket connection; the status change event includes at least one of the following: task start processing event, task completion event, task cancellation event, and task failure event.

5. The method according to claim 1, characterized in that, The step of determining the target record set from the data table based on the view context information includes: obtaining the configuration information of a predefined view based on the view identifier in the view context information, or directly querying based on the view condition parameters in the view context information to determine the record set that meets the view conditions.

6. The method according to claim 1, characterized in that, Also includes: Receive a task status query request sent by the client, wherein the task status query request includes a data table identifier; Based on the data table identifier, retrieve the task status information associated with the data table from the task status set and return it to the client.

7. The method according to claim 1, characterized in that, Also includes: Receive a task cancellation request sent by the client, the task cancellation request containing a task identifier; Update the status of the asynchronous populate task corresponding to the task identifier to the cancelled status, and send a cancellation signal to the task queue.

8. An asynchronous batch fill system based on view awareness in an intelligent data table, characterized in that, include: The request receiving module is used to obtain batch fill requests, which contain view context information. The view query module is used to determine the target record set from the data table based on the view context information; The task management module is used to generate task identifiers, create asynchronous fill tasks corresponding to the target record set, submit the asynchronous fill tasks to the task queue, and respond to the batch fill request by returning the task identifiers. The task execution module is used to obtain the asynchronous filling task through the task queue and execute it to fill the records in the target record set with data; The status management module is used to maintain a task status set, which records the status of the asynchronous filling task. The event push module is used to push a status change event to clients subscribed to the data table via a communication channel when the status of the asynchronous population task changes.

9. The system according to claim 8, characterized in that, The status management module maintains the task status set using data tables as the dimension. The task status set records the correspondence between field identifiers and task statuses. The system also includes a status query module and a task cancellation module. The status query module is used to receive a task status query request containing a data table identifier sent by the client, retrieve the task status information associated with the data table from the task status set according to the data table identifier, and return it to the client. The task cancellation module is used to receive a task cancellation request containing a task identifier sent by the client, update the status of the asynchronous population task corresponding to the task identifier to the cancelled status, and send a cancellation signal to the task queue.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the view-aware asynchronous batch filling method in the smart data table as described in any one of claims 1 to 7.

Images