Data service generation method, data service method and apparatus

Abstract

This specification provides one or more embodiments of a data service generation method, data service method, and apparatus. The method first receives descriptive information input by a user, which clarifies the data service development requirements of a target application. Then, it generates an SQL statement matching the descriptive information and, based on preset mapping rules between standardized model metadata and the SQL statement, transforms and generates a standardized data model corresponding to the data service. The model metadata associated with this standardized data model is persistently stored in a first database, providing metadata support for the entire data service operation process. In a second database, a schema-less document table corresponding to the data service is created, and various indexes adapted to the data service query requirements are constructed for this document table based on the model metadata.

Description

Technical Field

[0001] This specification relates to the field of software development technology, and in particular to a data service generation method, data service method and apparatus. Background Technology

[0002] With the deep penetration of artificial intelligence technology into the field of software development, various new software development paradigms are constantly emerging. Vibe Coding, as an innovative development model based on human-computer collaboration, takes immersive collaboration between developers and AI assistants using natural language as its core. It can quickly transform design ideas into executable programs, showing significant advantages in simplifying the development process, improving development efficiency, and shortening the cycle from proof of concept to a runnable prototype. It has become an important direction to support efficient application development.

[0003] In the practical implementation of ambient programming, persistent data storage is a key support for ensuring the application's practical value. Current implementations still require developers to frequently interrupt their immersive collaborative workflows to manually complete tasks such as database design, SQL writing, and data layer code implementation, which to some extent restricts overall development efficiency and user experience.

[0004] Therefore, there is an urgent need to propose a data service implementation scheme that adapts to the characteristics of ambient programming, so as to further improve the construction efficiency and development experience of data services in this scenario. Summary of the Invention

[0005] To address the aforementioned technical problems, this specification provides one or more embodiments of a data service generation method, a data service method, and an apparatus.

[0006] Firstly, one or more embodiments of this specification provide a data service generation method. This method is applied to an intelligent agent used to generate program code. The method includes: receiving descriptive information input by a user, the descriptive information describing the data service development requirements of a target application; generating a Structured Query Language (SQL) statement matching the descriptive information, the SQL statement representing the data structure of the data service; generating a standardized data model corresponding to the data service based on the mapping relationship between the SQL statement and preset standardized model metadata; persistently storing the model metadata corresponding to the standardized data model in a first database to provide metadata support for the data service; and creating a schema-less document table corresponding to the data service in a second database, and creating an index for the document table adapted to the data service query requirements based on the model metadata.

[0007] One possible implementation involves generating a standardized data model corresponding to the data service based on the mapping relationship between SQL statements and preset standardized model metadata. This includes: parsing the SQL statement into an abstract syntax tree (AST); extracting metadata about the data structure from the AST; and generating a standardized data model corresponding to the data service based on the mapping relationship between the metadata about the data structure and preset standardized model metadata.

[0008] In one possible implementation, the standardized model metadata includes attribute metadata, attribute type metadata, and data operation type, wherein each attribute type in the attribute type metadata maps to the backend storage type and the frontend no-code functional component.

[0009] In one possible implementation, the model metadata corresponding to the standardized data model is persistently stored in the first database to provide metadata support for the data service. This includes: persistently storing the model metadata corresponding to the standardized data model, as well as the mapping relationship between the model metadata and the version information of the target application, in the first database to provide metadata support for the data service.

[0010] In one possible implementation, the first database is a relational database, and the second database is a multimodal database.

[0011] Secondly, one or more embodiments of this specification provide a data service method, providing data services based on data services generated by the method of any one of the first aspects. The method includes: receiving a data access request initiated by a target application, wherein the data access request includes first request parameters of SQL syntax specifications; in response to receiving the data access request, obtaining model meta-information corresponding to the target application from a first database; converting the first request parameters into second request parameters supported by a second database based on the model meta-information; and performing data access operations on the second database based on the second request parameters.

[0012] In one possible implementation, the data access request further includes version information of the target application; wherein, in response to receiving the data access request, obtaining the model meta information corresponding to the target application from the first database includes: in response to receiving the data access request, obtaining the model meta information of the corresponding version of the target application from the first database based on the version information of the target application.

[0013] In one possible implementation, a data access operation is performed on the second database based on the second request input parameter, including: if the data access request is a write request, performing a write operation corresponding to the second request input parameter on the second database.

[0014] In one possible implementation, a data access operation is performed on the second database based on the second request input parameter, including: if the data access request is a read request, performing a read operation corresponding to the second request input parameter on the second database to obtain the first request output parameter supported by the second database; converting the first request output parameter into a second request output parameter conforming to SQL syntax based on model metadata; and feeding back the second request output parameter to the target application.

[0015] In one possible implementation, receiving a data access request initiated by the target application includes: receiving an authentication request initiated by the target application through an interface of an SDK compatible with SQL databases; sending a network token to the target application in response to the authentication request; receiving a data access request initiated by the target application, the data access request carrying the network token; authenticating the target application based on the network token; and, if the authentication is successful, routing the data access request to the data service interface.

[0016] Thirdly, one or more embodiments of this specification provide a data service generation apparatus, comprising: a first receiving module for receiving user-input descriptive information, the descriptive information describing the data service development requirements of a target application; a first generation module for generating a Structured Query Language (SQL) statement matching the descriptive information, the SQL statement representing the data structure of the data service; a second generation module for generating a standardized data model corresponding to the data service based on the mapping relationship between the SQL statement and preset standardized model metadata; a first storage module for persistently storing the model metadata corresponding to the standardized data model in a first database to provide metadata support for the data service; and a second storage module for creating a schema-less document table corresponding to the data service in the second database, and creating an index for the document table adapted to the data service query requirements based on the model metadata.

[0017] In one possible implementation, the second generation module is specifically used to parse the SQL statement into an abstract syntax tree (AST); extract the metadata of the data structure from the AST; and generate a standardized data model corresponding to the data service based on the mapping relationship between the metadata of the data structure and the metadata of the preset standardized model.

[0018] In one possible implementation, the standardized model metadata includes attribute metadata, attribute type metadata, and data operation type, wherein each attribute type in the attribute type metadata maps to the backend storage type and the frontend no-code functional component.

[0019] In one possible implementation, the first storage module is specifically used to persistently store the model metadata corresponding to the standardized data model, as well as the mapping relationship between the model metadata and the version information of the target application, in the first database to provide metadata support for data services.

[0020] In one possible implementation, the first database is a relational database, and the second database is a multimodal database.

[0021] Fourthly, one or more embodiments of this specification provide a data service apparatus, the apparatus comprising: a second receiving module, configured to receive a data access request initiated by a target application, wherein the data access request includes a first request parameter conforming to SQL syntax; an acquisition module, configured to, in response to receiving the data access request, acquire model metadata corresponding to the target application from a first database; a conversion module, configured to, based on the model metadata, convert the first request parameter into a second request parameter supported by a second database; and a data access module, configured to, based on the second request parameter, perform a data access operation on the second database.

[0022] In one possible implementation, the data access request also includes version information of the target application; the acquisition module is specifically used to, in response to receiving the data access request, acquire model meta-information of the corresponding version of the target application from the first database based on the version information of the target application.

[0023] In one possible implementation, the data access module is specifically used to perform the write operation corresponding to the second request parameters on the second database when the data access request is a write request.

[0024] In one possible implementation, the data access module is specifically used to perform a read operation on the second database corresponding to the second request input parameter when the data access request is a read request, to obtain the first request output parameter supported by the second database; based on the model meta information, convert the first request output parameter into the second request output parameter according to the SQL syntax specification; and feed back the second request output parameter to the target application.

[0025] In one possible implementation, the second receiving module is specifically used to receive an authentication request initiated by the target application through the interface of an SDK compatible with SQL databases; in response to the authentication request, send a network token to the target application; receive a data access request initiated by the target application, the data access request carrying the network token; authenticate the target application based on the network token; and if the authentication is successful, route the data access request to the data service interface.

[0026] Fifthly, one or more embodiments of this specification also provide an electronic device, which includes a memory and a processor; the memory is used to store a computer program product; the processor is used to execute the computer program product stored in the memory, and when the computer program product is executed, it implements the method of the first or second aspect described above.

[0027] Sixthly, one or more embodiments of this specification also provide a computer-readable storage medium storing computer program instructions that, when executed, implement the methods of the first or second aspect described above.

[0028] In summary, one or more embodiments of this specification provide a data service generation method, data service method, and apparatus. The method first receives descriptive information input by a user, which clarifies the data service development requirements of the target application. Then, it generates an SQL statement matching the descriptive information and, based on preset mapping rules between standardized model metadata and the SQL statement, transforms it into a standardized data model corresponding to the data service. The model metadata associated with this standardized data model is persistently stored in a first database, providing metadata support for the entire data service process. In a second database, a schema-less document table corresponding to the data service is created, and various indexes adapted to the data service query requirements are constructed for this document table based on the model metadata. This achieves full automation of the data service process from requirement description to storage, ensuring smooth programming and development efficiency.

[0029] In this way, through the aforementioned layer-by-layer automated processing flow from data service development requirements to standardized data models, and from standardized data models to storage, AI can automatically identify and understand data persistence requirements throughout the entire ambient programming process. Based on standardized model metadata, it can automatically generate database structures, construct data models, and automatically generate and uniformly manage related data layer code, thereby decoupling the strong relationship between upper-layer logic and lower-layer data operations. Furthermore, since a standardized data model serves as the unified basis for the entire process, it can directly and automatically complete the creation of schema-less document tables and the configuration of query indexes based on this model metadata. Developers are not required to manually design database structures, write SQL statements, or implement data access logic. This effectively prevents developers from interrupting the immersive collaborative process during ambient programming by handling data persistence-related tasks, significantly reducing context switching costs and manual intervention workload, further aligning with the efficient and smooth development requirements of ambient programming. Attached Figure Description

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

[0031] Figure 1A flowchart illustrating a data service generation method provided in one or more embodiments of this specification; Figure 2 A flowchart illustrating a data service method provided in one or more embodiments of this specification; Figure 3 A flowchart illustrating yet another data service method provided in one or more embodiments of this specification; Figure 4 A structural block diagram of a data service generation apparatus provided in one or more embodiments of this specification; Figure 5 A structural block diagram of a data service device provided in one or more embodiments of this specification; Figure 6 This is a structural block diagram of an electronic device provided for one or more embodiments of this specification. Detailed Implementation

[0032] The present specification describes one or more embodiments in further detail below with reference to the accompanying drawings and examples. Through these descriptions, the features and advantages of one or more embodiments of the present specification will become clearer and more apparent.

[0033] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments. Although various aspects of embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated otherwise.

[0034] Furthermore, the technical features described below in one or more embodiments of this specification may be combined with each other as long as they do not conflict with each other.

[0035] To facilitate understanding, the application scenarios of the technical solutions provided in one or more embodiments of this specification will be described below.

[0036] Vibe Coding, a new software development paradigm emerging in the era of artificial intelligence, centers on immersive collaboration between developers and AI assistants using natural language. It's a development model that leverages human-machine collaboration to rapidly transform design ideas into executable programs. In this paradigm, developers no longer need to frequently switch between multiple tools such as documentation and integrated development environments. They only need to clearly describe functional requirements using natural language, and AI will automatically generate the corresponding code. This significantly improves development efficiency, reduces context switching costs, and drastically shortens the implementation cycle from proof of concept to a runnable prototype.

[0037] However, while ambient programming begins with design principles based on natural language, its core goal is to generate applications with practical value. Applications with practical functionality typically require persistent storage of data state, and related technologies are still predominantly based on Structured Query Language (SQL) for the data manipulation layer to build data storage systems. Because SQL's scope is limited to backend data storage, retrieval, and transaction processing, it cannot effectively decouple upper-level logic from the data manipulation layer, making it difficult for AI to directly understand and manipulate the database structure. For example, AI cannot automatically generate suitable table creation statements or data access logic that matches the current storage structure. This forces developers to frequently interrupt the immersive collaborative process during ambient programming to manually perform database design, SQL writing, and data layer code implementation, thus reducing the development efficiency and usability of the ambient programming paradigm.

[0038] To address the technical problem in ambient programming development where SQL-based data storage systems fail to decouple upper-level logic from the data operation layer, leading to frequent interruptions in the developer's immersive collaborative process and reduced development efficiency, this specification provides a data service generation method through one or more embodiments. The method first receives user-input description information, which clarifies the data service development requirements of the target application. Then, it generates an SQL statement matching the description information and, based on preset mapping rules between standardized model metadata and the SQL statement, transforms it into a standardized data model corresponding to the data service. The model metadata associated with this standardized data model is persistently stored in a first database, providing metadata support for the entire data service process. In a second database, a schema-less document table corresponding to the data service is created, and various indexes adapted to the data service query requirements are constructed for this document table based on the model metadata. This achieves full automation of the data service process from requirement description to storage, ensuring the smoothness and efficiency of ambient programming.

[0039] In this way, through the aforementioned layer-by-layer automated processing flow from data service development requirements to standardized data models, and from standardized data models to storage, AI can automatically identify and understand data persistence requirements throughout the entire ambient programming process. Based on standardized model metadata, it can automatically generate database structures, construct data models, and automatically generate and uniformly manage related data layer code, thereby decoupling the strong relationship between upper-layer logic and lower-layer data operations. Furthermore, since a standardized data model serves as the unified basis for the entire process, it can directly and automatically complete the creation of schema-less document tables and the configuration of query indexes based on this model metadata. Developers are not required to manually design database structures, write SQL statements, or implement data access logic. This effectively prevents developers from interrupting the immersive collaborative process during ambient programming by handling data persistence-related tasks, significantly reducing context switching costs and manual intervention workload, further aligning with the efficient and smooth development requirements of ambient programming.

[0040] The following describes embodiments of the data service generation method provided in one or more embodiments of this specification.

[0041] See Figure 1 , Figure 1 This is a flowchart illustrating a data service generation method provided in one or more embodiments of this specification. This method can be applied to intelligent agents used to generate program code, development platforms for these intelligent agents, electronic devices, etc. Figure 1 As shown, the method may include the following steps: Step S102: Receive the description information input by the user.

[0042] In ambient programming development scenarios, users can interact with intelligent agents and input descriptive information to the agents to describe the data service development requirements of the target application.

[0043] For example, in an integrated development environment (IDE), a user might use natural language to request an AI assistant to "develop a task management application that supports the creation, querying, updating, and deletion of tasks. Each task should include a title, completion status, priority, and creation time field, with priority values ​​ranging from 1 to 3 (numeric type)." Here, the task management application is the target application, and the requirement to "support the creation, querying, updating, and deletion of tasks, with tasks including a title, completion status, priority, and creation time field, with priority values ​​ranging from 1 to 3 (numeric type)" represents the data service development requirement.

[0044] Step S104: Generate a Structured Query Language (SQL) statement that matches the description information.

[0045] One possible implementation is to integrate a software development kit (SDK) compatible with SQL-based databases into the development platform. After the agent parses the data service development requirements, it can call the SDK to generate SQL statements that match the data service development requirements, thereby achieving an automated connection from requirement parsing to SQL statement generation without manual intervention from the developer.

[0046] For example, the aforementioned SDK compatible with SQL databases can adopt an SDK compatible with open-source Backend-as-a-Service (BaaS) platforms. These platforms provide standardized data access interfaces based on SQL databases, automatically generating data access logic and application programming interfaces. They offer lightweight, out-of-the-box data service support for AI-generated SQL statements, further lowering the technical barrier to AI-generated SQL statements and shortening the development cycle.

[0047] In other words, the generated SQL statements are used to represent the data structure of the data service. For example, the generated SQL statements may include DDL statements (schema operation statements such as creating and modifying tables) and DML statements (data operation statements such as adding, deleting, modifying, and querying) that conform to the SQL syntax specification.

[0048] In this way, by integrating an SDK compatible with SQL-based databases, the process of generating SQL statements from natural language requirements can be automated, eliminating the need for developers to manually write DDL / DML statements and significantly lowering the technical barrier to data service development in programming scenarios. Furthermore, relying on the standardized interfaces of the open-source BaaS platform, lightweight, out-of-the-box data service support is provided, shortening the initial development cycle of data services and preventing developers from interrupting their immersive collaboration due to writing SQL.

[0049] Step S106: Based on the mapping relationship between SQL statements and preset standardized model metadata, generate a standardized data model corresponding to the data service.

[0050] This specification introduces standardized model metadata in one or more embodiments. Standardized model metadata is a predefined, structured set of rules that can be automatically parsed by AI and systems. It specifies the mapping rules from SQL statements to standardized data models, field attribute specifications, data type correspondences, index configuration standards, and other core content. It serves as a translation manual for converting SQL statements into a unified data model and is also the core basis for ensuring the automation and standardization of the entire data service process.

[0051] Specifically, the SQL statement describes the "physical structure of the data (such as field names and types)," while the standardized model metadata defines "how to transform the physical structure information in the SQL into a standardized data model that the system can uniformly recognize and call." Moreover, this set of rules is pre-set and does not require manual adjustment by developers, thus achieving decoupling while reducing the cost of manual intervention.

[0052] For example, standardized model metadata may include attribute metadata, attribute type metadata, and data operation types.

[0053] For example, basic attribute metadata may include attribute label, attribute name, attribute index, attribute ID, attribute type, whether it is required, whether it is a primary key, whether it is retained, whether it is read-only / custom, whether query is enabled, etc.

[0054] Attribute type metadata can include Boolean types, text types, region types, attachment types, image types, numeric types, date and time types, selection list types, long text types, date types containing types, relational types, etc. Taking numeric types as an example, they can include integer digits, decimal digits, maximum value, minimum value, etc.

[0055] In particular, each attribute type in the attribute type metadata maps to the backend storage type and the frontend no-code functional component, further strengthening the decoupling effect between the upper-layer logic and the lower-layer storage.

[0056] Data operation types can include creation, deletion, update, code retrieval, query, batch deletion, batch update, etc.

[0057] In one possible implementation, the standardized data model corresponding to the data service is generated based on the mapping relationship between the SQL statement and the preset standardized model meta-information. This can be achieved by the following method: first, the SQL statement is parsed into an abstract syntax tree (AST), and the meta-information of the data structure is extracted from the AST. Then, based on the mapping relationship between the meta-information of the data structure and the preset standardized model meta-information, the standardized data model corresponding to the data service is generated.

[0058] For example, continuing with the task management application development requirements, the generated SQL statement can be parsed into an AST, from which metadata such as table name tasks, field names (title, isCompleted, priority, createdAt), field types (text, boolean, number, date and time), field constraints (title is a non-null field, priority has a value range of 1-3), and index information (createdAt field is configured to query index) can be extracted.

[0059] Based on the above standardized model metadata definition, a standardized data model corresponding to this task management application is constructed, and the specific mapping rules are as follows: The title field: maps to attribute metadata of type TEXT and is marked as a non-null constraint; The isCompleted field: Attribute metadata mapped to type BOOLEAN; The priority field: Mapped to attribute metadata of type NUMBER, configured with integer digitLeft=1, decimal digits scale=0, maximum value max=3, and minimum value min=1; The `createdAt` field: maps to attribute metadata of type DATE_TIME and configures the query index; Additionally, configure the core action types: CREATE, DELETE, UPDATE, and QUERY.

[0060] In this way, based on a pre-defined set of standardized model metadata rules, the physical structure information (fields, types, constraints, indexes) extracted from SQL parsing is mapped to a unified abstract data model. This achieves a dimensional transformation of data structure from a physical definition at the storage layer to a standardized definition at the model layer, thereby solving the technical problems of SQL's inability to decouple upper-level logic from the data operation layer and AI's inability to build a unified data model. By explicitly defining metadata such as field constraints, data type mappings, and operation types, the consistency between front-end component validation and back-end storage constraints is ensured, eliminating the risk of anomalies caused by inconsistencies in cross-layer rules. Simultaneously, it provides a unified basis for subsequent storage deployment and parameter conversion, avoiding the need for developers to manually coordinate cross-layer differences.

[0061] Step S108: Persistently store the model metadata corresponding to the standardized data model in the first database to provide metadata support for data services.

[0062] Optionally, the first database can be a relational database to ensure the standardization of model metadata storage and query efficiency.

[0063] In one possible implementation, the model metadata corresponding to the standardized data model, as well as the mapping relationship between the model metadata and the version information of the target application, can be persistently stored in the first database.

[0064] For example, corresponding model meta-information can be created and bound for task management application version V1.0, or model meta-information for other versions of the application can be created and bound to achieve accurate association between different versions of the same application and the corresponding model.

[0065] This persistently stores the mapping relationship between model metadata and application version information in a relational database, enabling independent storage, precise binding, and differentiated management of multiple application version models, avoiding mutual interference between different version models; it also provides standardized data support for model version rollback, comparison, and upgrade, adapting to the management needs of rapid application iteration, ensuring the traceability and manageability of the entire model lifecycle, further reducing the workload of developers manually managing model metadata, and avoiding interruptions to immersive collaboration.

[0066] Step S110: Create a schema-less document table corresponding to the data service in the second database, and create an index for the document table that adapts to the query requirements of the data service based on the model metadata.

[0067] To address the issues of traditional static schema storage being unsuitable for agile development and requiring developers to manually create indexes, leading to low development efficiency, this specification provides one or more embodiments for creating schema-less document tables corresponding to data services in a second database, without defining specific fields. This allows for dynamic adjustments to the data structure during development, eliminating the need for pre-defined complex table structures or migration scripts, significantly improving model iteration speed and meeting the demands of rapid iteration in agile programming.

[0068] For example, creating an index for a document table based on model metadata to meet the data service query requirements may include: creating a regular index for the createdAt field, a full-text index for the title field, and a query index for the priority field in a second database based on the model metadata.

[0069] Optionally, the second database can be a multimodal database, such as MongoDB. Multimodal databases can natively support data schemas such as document, key-value, and time-series data on the same platform, and can integrate full-text search and vector search capabilities, reducing external dependencies, further simplifying the technical architecture, and lowering the operational costs for developers.

[0070] In this way, creating schema-less document tables in a multimodal database supports dynamic adjustments to the data structure without the need to predefine complex table structures or execute migration scripts, greatly improving the model iteration speed. At the same time, indexes (normal indexes, full-text indexes, and query indexes) are created specifically based on model metadata, optimizing the query performance of data services while ensuring the flexibility of the data structure. Relying on the native multi-type data support capabilities of the multimodal database, the dependence on external retrieval components is reduced, the technical architecture is simplified, and the manual operation and maintenance workload of developers is further reduced, avoiding interruptions to the immersive collaboration process.

[0071] In summary, the data service generation method provided by one or more embodiments of this specification forms an end-to-end automated data service generation chain, from natural language requirement input to SQL generation, standardized model construction, metadata persistence, and document table and index creation. The entire process does not require manual intervention by developers in core steps, solving the technical problems of "strong coupling between upper-level logic and data operation layer, AI's inability to automatically handle persistence requirements, and developers' need to frequently interrupt immersive collaboration" in ambient programming scenarios, and significantly improving the development efficiency of data services in ambient programming scenarios.

[0072] This specification also provides a data service method in one or more embodiments, which can be implemented based on the data service obtained in the above embodiments. It can also be understood that the data service method represents the implementation and usage phase of the data service obtained above.

[0073] See Figure 2 , Figure 2 This is a flowchart illustrating a data service method provided in one or more embodiments of this specification. The method can be applied to an electronic device, which can serve as a server. Figure 2 As shown, the method may include the following steps: Step S202: Receive a data access request initiated by the target application.

[0074] In one possible implementation, the server can receive authentication requests initiated by the target application through the interface of an SDK compatible with SQL databases; in response to the authentication request, send a network token to the target application; receive data access requests initiated by the target application, the data access requests carrying the network token; authenticate the target application based on the network token; and if the authentication is successful, route the data access request to the data service interface.

[0075] For example, such as Figure 3 As shown, the application can initiate an authentication request to the data server through the integrated Supabase-compatible SDK. The request can carry basic authentication information (such as the developer API key, application unique identifier, etc.). The server can verify the legality of the basic authentication information (such as whether the key is valid and whether the application has the necessary permissions). After successful verification, the server can generate a network token containing core information (such as user / application ID, permission scope, token validity period, etc.) and ensure that the token is not tampered with through encryption and signature. The SDK receives the token returned by the server and caches it locally as an identity credential for subsequent requests.

[0076] After authentication is complete, when the application initiates a specific data access request (such as querying / adding / modifying data), the SDK can automatically add the cached token to the request header. After receiving the data access request, the server can first parse the token in the request header and perform dual verification: verifying whether the token signature is valid; verifying whether the token is within its validity period and whether the permissions match the current request; if the verification passes, the server processes the data access request normally and returns the corresponding result; if the verification fails, the server can directly reject the request, return an authentication error message, and not perform any data operations.

[0077] The data access request may include a first request parameter conforming to the SQL syntax specification. Taking a task management application as an example, when a user clicks "Create Task" on the front-end page of the task management application, and enters the task title "Learning Model Driven Architecture" and priority 2, the front-end first initiates an authentication request and obtains a token through the aforementioned SDK; then, it sends a data access request for creating the task with the token. This data access request carries structured data conforming to the SQL specification, corresponding to the first request parameter "Task Title Learning Model Driven Architecture, Priority 2".

[0078] In this way, by using an SDK interface compatible with SQL-based databases to complete authentication and data access request reception, and by implementing request legitimacy verification based on network tokens, the problem of lacking unified identity verification for data access and requiring developers to manually handle authentication logic can be solved. Furthermore, it can perform unified identity authentication and permission verification for data access requests without disrupting the development habits of upper-layer applications, ensuring the security and controllability of data access. Standardized interfaces are compatible with mainstream development ecosystems, reducing application integration costs, improving the universality and stability of the overall process, further avoiding manual intervention in the authentication process by developers, and ensuring the smoothness of immersive collaboration.

[0079] Step S204: In response to receiving a data access request, obtain the model meta-information corresponding to the target application from the first database.

[0080] The first database is used to store the model metadata corresponding to the target application. For details about the model metadata, please refer to the descriptions of steps S102 to S110, which will not be repeated here.

[0081] Data access requests can carry the identification information of the target application. After receiving the data access request, the server retrieves the corresponding model meta-information from the first database based on the identification information of the target application.

[0082] In one possible implementation, the data access request can also carry the version information and identification information of the target application. In this way, after receiving the data access request, the server can obtain the model meta information of the corresponding version of the target application from the first database based on the version information and identification information of the target application.

[0083] In this way, in response to data access requests, the corresponding model metadata is retrieved from the first database based on the application identifier and version information. This enables the rapid and accurate location and loading of the data structure description information for the corresponding version of the target application. This provides a unified and standardized basis for subsequent request parameter conversion and data operation execution, ensuring that the data access logic of different versions and applications does not interfere with each other, improving system scalability and version compatibility. Developers do not need to manually match model metadata, further reducing manual intervention and ensuring smooth collaboration.

[0084] Step S206: Based on the model meta information, convert the first request input parameters into second request input parameters supported by the second database.

[0085] The first request parameter is a request parameter that conforms to the SQL syntax specification carried in the data access request. After obtaining the model metadata of the target application, the server converts the request parameter that conforms to the SQL syntax specification into a standardized request parameter supported by the second database, which is the second request parameter.

[0086] For example, the server retrieves the model metadata of the task management application version V1.0 from the first database, and converts the structured request parameters that conform to the SQL specification passed in from the front end into request parameters in the JSON document format supported by the second database.

[0087] In this way, based on the model meta information, the first request parameters of the SQL syntax specification are converted into the second request parameters supported by the second database, realizing the automatic conversion of parameter formats between standard SQL requests and schema-less document-type storage. This decouples the upper-layer application from the underlying storage structure, allowing the upper-layer application to complete data interaction without having to pay attention to the actual storage format of the second database, significantly improving the smoothness of development and avoiding developers manually converting parameters and interrupting immersive collaboration.

[0088] Step S208: Based on the second request input parameters, perform data access operations on the second database.

[0089] When the data access request is a write request (such as adding, modifying, or deleting data), the server performs the corresponding write operation on the second database based on the input parameters of the second request. For example, task data in JSON format is inserted into the tasks document table of the second database.

[0090] When the data access request is a read request, the server performs the corresponding read operation on the second database based on the second request input parameters, and obtains the first request output parameters in the original format of the second database; then, based on the model meta information, the first request output parameters are converted into second request output parameters that conform to the SQL syntax specification; finally, the second request output parameters are fed back to the target application.

[0091] For example, the server reads task data in JSON format from the tasks document table in the second database, converts the JSON data into structured data that conforms to SQL syntax based on the model meta information of the task management application V1.0, and then returns it to the front-end page of the application for display.

[0092] In this way, based on the transformed second request parameters, corresponding data access operations are performed on the second database, enabling unified support for automated processing of both read and write requests. This solves the problems of manually adapting storage formats and inconsistent read / write logic required for data access operations. Data persistence is directly completed in write request scenarios, while the storage layer results are automatically converted back to a standard format in read request scenarios, achieving end-to-end automation from request to response. This further improves the execution efficiency and user experience of data services in immersive programming, avoids developers manually handling data access logic, and ensures uninterrupted immersive collaboration.

[0093] In summary, the data service method of one or more embodiments of this specification, through steps such as loading model metadata, converting request parameters, and executing data access, automatically converts SQL-standard request parameters into a storage format supported by a second database. This removes the strong dependency between upper-layer development logic and lower-layer storage implementation, enabling AI to automatically understand data persistence requirements and automatically complete database structure parsing, parameter conversion, and data operation execution in the ambient programming process. Combined with the data service generation method described above, this method comprehensively solves the technical problems in ambient programming scenarios, such as strong coupling between upper-layer applications and lower-layer data storage, AI's inability to automatically understand and process persistence requirements, and the need for developers to frequently interrupt immersive collaboration processes. It significantly improves the development efficiency, fluency, and automation level of the ambient programming paradigm, meeting the development needs of human-machine collaboration and rapid iteration.

[0094] The following provides an exemplary description of the data service generation method and the overall scheme of the data service method.

[0095] like Figure 3 As shown, this method may include a model-driven layer, a runtime layer, and an integrated storage layer.

[0096] The model-driven layer is responsible for transforming natural language requirements into a standardized, understandable data model. For example, it can receive natural language requirements from developers, generate SQL-compliant program code using AI, parse the generated SQL statements into an Abstract Syntax Tree (AST), extract meta-information such as fields, constraints, and indexes, and then transform it into a standardized data model according to preset rules. Finally, it persistently stores the standardized model meta-information through model meta-information management, while also supporting version management, providing a unified and traceable basis for subsequent data access. For details, please refer to the description of the data service generation method embodiment; it will not be repeated here.

[0097] The runtime layer is the core scheduling center of the data service, responsible for handling data access requests from the application. For example, data access requests include: Authentication: Using an SDK interface compatible with SQL-based databases, application authentication is completed and a JWT token is issued to ensure data access security. Data Service: As the core scheduling unit, it receives and routes all requests, while coordinating the following key sub-modules: Request Forwarding: Legitimate requests are distributed to the corresponding processing units. Response Feedback: Database operation results are returned to the application in SQL-compliant format. Model Meta-information Query: The model meta-information corresponding to the target application version is accurately loaded from the first database as the basis for parameter conversion. Write Request Processing: SQL-compliant write request parameters are converted to a format supported by schema-less storage, and data persistence is performed. Read Request Processing: After executing the query, the results in the storage layer's native format are converted back to SQL-compliant format and returned. For details, please refer to the description of the data service method embodiment; it will not be repeated here.

[0098] The integrated storage layer provides a flexible, high-performance storage platform, supporting dynamic schemas and efficient queries. PolygonStore, as the primary storage engine, employs a schema-less document-oriented storage model, supporting dynamic adjustments to the data structure without requiring predefined schemas or migration scripts. It features built-in document storage, index management, and full-text indexing capabilities, automatically creating indexes tailored to query needs based on model metadata, optimizing query performance while ensuring flexibility.

[0099] It is understood that the above embodiments are merely examples, and modifications can be made to the above embodiments in actual implementation. Those skilled in the art will understand that any modifications to the above embodiments that do not require creative effort fall within the protection scope of one or more embodiments of this specification, and will not be described again in the embodiments.

[0100] Based on the same inventive concept, one or more embodiments of this specification also provide a data service generation apparatus and a data service apparatus. Since the principle by which the data service generation apparatus solves the problem is similar to that of the aforementioned data service generation method, the implementation of the data service generation apparatus can refer to the implementation of the aforementioned data service generation method, and repeated details will not be repeated. Similarly, since the principle by which the data service apparatus solves the problem is similar to that of the aforementioned data service method, the implementation of the data service apparatus can refer to the implementation of the aforementioned data service method, and repeated details will not be repeated.

[0101] See Figure 4 , Figure 4 This is a structural block diagram of a data service generation apparatus provided in one or more embodiments of this specification. Figure 4 As shown, the data service generation device 300 may include: a first receiving module 301, a first generation module 302, a second generation module 303, a first storage module 304, and a second storage module 305. Among them, The first receiving module 301 is used to receive descriptive information input by the user, which describes the data service development requirements of the target application.

[0102] The first generation module 302 is used to generate a structured query language (SQL) statement that matches the description information. The SQL statement is used to represent the data structure of the data service.

[0103] The second generation module 303 is used to generate a standardized data model corresponding to the data service based on the mapping relationship between SQL statements and preset standardized model metadata.

[0104] The first storage module 304 is used to persistently store the model metadata corresponding to the standardized data model in the first database to provide metadata support for data services.

[0105] The second storage module 305 is used to create schema-less document tables corresponding to the data service in the second database, and to create indexes for the document tables based on model metadata to adapt to the query requirements of the data service.

[0106] In one possible implementation, the second generation module 303 is specifically used to parse the SQL statement into an abstract syntax tree (AST); extract the metadata of the data structure from the AST; and generate a standardized data model corresponding to the data service based on the mapping relationship between the metadata of the data structure and the metadata of the preset standardized model.

[0107] In one possible implementation, the standardized model metadata includes attribute metadata, attribute type metadata, and data operation type, wherein each attribute type in the attribute type metadata maps to the backend storage type and the frontend no-code functional component.

[0108] In one possible implementation, the first storage module 304 is specifically used to persistently store the model metadata corresponding to the standardized data model, as well as the mapping relationship between the model metadata and the version information of the target application, in the first database to provide metadata support for data services.

[0109] In one possible implementation, the first database is a relational database, and the second database is a multimodal database.

[0110] See Figure 5 , Figure 5 This is a structural block diagram of a data service device provided for one or more embodiments of this specification. Figure 5 As shown, the data service device 400 may include: a second receiving module 401, an acquisition module 402, a conversion module 403, and a data access module 405. Among them, The second receiving module 401 is used to receive a data access request initiated by the target application, wherein the data access request includes the first request parameters of the SQL syntax specification.

[0111] The acquisition module 402 is used to obtain the model meta-information corresponding to the target application from the first database in response to receiving a data access request; The conversion module 403 is used to convert the first request input parameters into second request input parameters supported by the second database based on the model meta information. The data access module 404 is used to perform data access operations on the second database based on the second request input parameters.

[0112] In one possible implementation, the data access request also includes version information of the target application; the acquisition module 402 is specifically used to, in response to receiving the data access request, acquire model meta-information of the corresponding version of the target application from the first database based on the version information of the target application.

[0113] In one possible implementation, the data access module 404 is specifically used to perform a write operation on the second database corresponding to the second request parameters when the data access request is a write request.

[0114] In one possible implementation, the data access module 404 is specifically used to perform a read operation on the second database corresponding to the second request input parameter when the data access request is a read request, to obtain the first request output parameter supported by the second database; based on the model meta information, convert the first request output parameter into the second request output parameter according to the SQL syntax specification; and feed back the second request output parameter to the target application.

[0115] In one possible implementation, the second receiving module 401 is specifically used to receive an authentication request initiated by the target application through the interface of an SDK compatible with SQL databases; in response to the authentication request, send a network token to the target application; receive a data access request initiated by the target application, the data access request carrying the network token; authenticate the target application based on the network token; and if the authentication is successful, route the data access request to the data service interface.

[0116] See Figure 6 , Figure 6 This is a structural block diagram of an electronic device provided for one or more embodiments of this specification. Figure 6 As shown, the electronic device 500 may include a processor 501 and a memory 502; the memory 502 may be coupled to the processor 501. It is worth noting that... Figure 6 This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions.

[0117] In one possible implementation, the functions of the data service generation device or the data service device can be integrated into the processor 501. The processor 501 can be configured to perform the following operations: The system receives user-input description information, which describes the data service development requirements of the target application; generates a Structured Query Language (SQL) statement that matches the description information, which represents the data structure of the data service; generates a standardized data model corresponding to the data service based on the mapping relationship between the SQL statement and pre-defined standardized model metadata; persistently stores the model metadata corresponding to the standardized data model in a first database to provide metadata support for the data service; and creates a schema-less document table corresponding to the data service in a second database, and creates an index for the document table based on the model metadata that adapts to the query requirements of the data service.

[0118] Alternatively, processor 501 can be configured to perform the following operations: The system receives a data access request initiated by the target application, wherein the data access request includes a first request parameter in accordance with the SQL syntax specification; in response to receiving the data access request, it obtains the model meta information corresponding to the target application from the first database; based on the model meta information, it converts the first request parameter into a second request parameter supported by the second database; and based on the second request parameter, it performs a data access operation on the second database.

[0119] In another possible implementation, the data service generation device or data service device can be configured separately from the processor 501. For example, the data service generation device or data service device can be configured as a chip connected to the processor 501, and the generation of data services or data services can be realized through the control of the processor 501.

[0120] Furthermore, in some alternative implementations, the electronic device 500 may also include: a communication module, an input unit, an audio processor, a display, a power supply, etc. It is worth noting that the electronic device 500 is not necessarily required to include these components. Figure 6 All components shown; in addition, the electronic device 500 may also include Figure 6 For components not shown, please refer to existing technologies.

[0121] In some alternative implementations, the processor 501, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device, which receives input and controls the operation of various components of the electronic device 500.

[0122] The memory 502 may be, for example, one or more of a cache, flash memory, hard drive, removable medium, volatile memory, non-volatile memory, or other suitable means. It may store the aforementioned information related to the data service generation apparatus or data service apparatus, and may also store programs for executing that information. The processor 501 may execute the program stored in the memory 502 to perform information storage or processing, etc.

[0123] An input unit can provide input to the processor 501. This input unit may be, for example, a button or touch input device. A power supply can be used to provide power to the electronic device 500. A display can be used to display images and text, etc. This display may be, for example, an LCD display, but is not limited to this.

[0124] Memory 502 can be a solid-state memory, such as read-only memory (ROM), random access memory (RAM), SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROM, etc. Memory 502 can also be some other type of device. Memory 502 includes buffer memory (sometimes referred to as a buffer). Memory 502 may include an application / function storage unit for storing application programs and function programs or processes for executing the operation of electronic device 500 via processor 501.

[0125] The memory 502 may also include a data storage unit for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit of the memory 502 may include various drivers for the computer device for communication functions and / or for performing other functions of the computer device (such as messaging applications, address book applications, etc.).

[0126] The communication module is a transmitter / receiver that sends and receives signals via an antenna. The communication module (transmitter / receiver) is coupled to the processor 501 to provide input signals and receive output signals, which is the same as in a conventional mobile communication terminal.

[0127] Based on different communication technologies, multiple communication modules can be configured in the same computer device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication modules (transmitters / receivers) are also coupled to speakers and microphones via an audio processor to provide audio output through the speakers and receive audio input from the microphones, thereby enabling typical telecommunications functions. The audio processor may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor is coupled to processor 501, enabling on-device recording via the microphone and on-device playback of stored sound via the speakers.

[0128] This specification also provides one or more embodiments of a computer-readable storage medium capable of implementing all steps of the data service generation method or data service method in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the data service generation method or data service method in the above embodiments. While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive labor. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual device or client product execution, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment).

[0129] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, apparatus (systems), or computer program products. Therefore, the embodiments of this specification can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, one or more embodiments of this specification can take the form of a computer program product implemented 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.

[0130] This specification describes one or more embodiments of a method, apparatus (system), and computer program product according to one or more embodiments of this specification with reference to flowchart illustrations and / or block diagrams. 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. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0131] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0132] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0133] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and system embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0134] In this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, without necessarily requiring or implying any such actual relationship or order between these entities or operations. Furthermore, 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 a process, method, article, or apparatus. Those skilled in the art will understand the specific meaning of the above terms in one or more embodiments of this specification, depending on the specific circumstances.

[0135] It should be noted that, unless otherwise specified, one or more embodiments and features thereof in this specification can be combined with each other. This specification is not limited to any single aspect, nor to any single embodiment, nor to any combination and / or substitution of such aspects and / or embodiments. Furthermore, each aspect and / or embodiment of one or more embodiments of this specification can be used alone or in combination with one or more other aspects and / or embodiments thereof.

[0136] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of one or more embodiments of this specification, and are not intended to limit them. Although one or more embodiments of this specification have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of one or more embodiments of this specification, and they should all be covered within the scope of the claims and the specification of one or more embodiments of this specification.

[0137] The foregoing description of one or more embodiments of this specification has been provided in conjunction with optional implementation methods. However, these embodiments are merely exemplary and serve only an illustrative purpose. Based on this, various substitutions and modifications can be made to one or more embodiments of this specification, all of which fall within the protection scope of one or more embodiments of this specification.

Claims

1. A method for generating data services, characterized in that, The method is applied to an intelligent agent used to generate program code, and the method includes: Receive description information input by the user, the description information being used to describe the data service development requirements of the target application; Generate a Structured Query Language (SQL) statement that matches the description information, the SQL statement being used to represent the data structure of the data service; Based on the mapping relationship between the SQL statement and the preset standardized model meta information, a standardized data model corresponding to the data service is generated. The model metadata corresponding to the standardized data model is persistently stored in the first database to provide metadata support for the data service; Create a schemaless document table corresponding to the data service in the second database, and create an index for the document table that adapts to the query requirements of the data service based on the model metadata.

2. The method according to claim 1, characterized in that, The process of generating a standardized data model corresponding to the data service based on the mapping relationship between the SQL statement and preset standardized model metadata includes: The SQL statement is parsed into an Abstract Syntax Tree (AST). Extract metadata about the data structure from the AST; Based on the mapping relationship between the metadata of the data structure and the metadata of the preset standardized model, a standardized data model corresponding to the data service is generated.

3. The method according to claim 1 or 2, characterized in that, The standardized model metadata includes attribute metadata, attribute type metadata, and data operation type, wherein each attribute type in the attribute type metadata maps to a backend storage type and a frontend no-code functional component.

4. The method according to claim 1, characterized in that, The step of persistently storing the model metadata corresponding to the standardized data model in the first database to provide metadata support for the data service includes: The model metadata corresponding to the standardized data model, and the mapping relationship between the model metadata and the version information of the target application, are persistently stored in the first database to provide metadata support for the data service.

5. The method according to claim 1, characterized in that, The first database is a relational database, and the second database is a multimodal database.

6. A data service method, characterized in that, Provide data services based on data services generated by the method described in any one of claims 1-5, the method comprising: Receive a data access request initiated by the target application, wherein the data access request includes a first request parameter of the SQL syntax specification; In response to receiving the data access request, the model meta-information corresponding to the target application is obtained from the first database; Based on the model meta information, the first request input parameter is converted into a second request input parameter supported by the second database; Based on the second request parameters, perform data access operations on the second database.

7. The method according to claim 6, characterized in that, The data access request also includes the version information of the target application; The step of retrieving the model metadata corresponding to the target application from the first database in response to receiving the data access request includes: In response to receiving the data access request, the system retrieves the corresponding version of the target application's model meta-information from the first database based on the target application's version information.

8. The method according to claim 6, characterized in that, Based on the second request input parameters, perform data access operations on the second database, including: If the data access request is a write request, the write operation corresponding to the second request input parameter is executed on the second database.

9. The method according to claim 6, characterized in that, Based on the second request input parameters, perform data access operations on the second database, including: When the data access request is a read request, the read operation corresponding to the second request input parameter is performed on the second database to obtain the first request output parameter supported by the second database; Based on the model meta information, the first request parameters are converted into second request parameters conforming to SQL syntax. The second request parameters are fed back to the target application.

10. The method according to claim 6, characterized in that, The receiving of data access requests initiated by the target application includes: Receive authentication requests initiated by the target application through the interface of the SDK that is compatible with SQL databases; In response to the authentication request, a network token is sent to the target application; Receive a data access request initiated by the target application, the data access request carrying the network token; The target application is authenticated based on the network token; If authentication is successful, the data access request is routed to the data service interface.

11. A data service generation apparatus, characterized in that, The device includes: The first receiving module is used to receive descriptive information input by the user, the descriptive information being used to describe the data service development requirements of the target application; The first generation module is used to generate a structured query language (SQL) statement that matches the description information, wherein the SQL statement is used to represent the data structure of the data service; The second generation module is used to generate a standardized data model corresponding to the data service based on the mapping relationship between the SQL statement and the preset standardized model meta information. The first storage module is used to persistently store the model metadata corresponding to the standardized data model in the first database to provide metadata support for the data service; The second storage module is used to create a schemaless document table corresponding to the data service in the second database, and to create an index for the document table that adapts to the query requirements of the data service based on the model metadata.

12. A data service device, characterized in that, The device includes: The second receiving module is used to receive a data access request initiated by the target application, wherein the data access request includes a first request parameter of the SQL syntax specification; The acquisition module is used to, in response to receiving the data access request, acquire the model meta-information corresponding to the target application from the first database; The conversion module is used to convert the first request input parameter into a second request input parameter supported by the second database based on the model meta information. The data access module is used to perform data access operations on the second database based on the second request input parameters.

13. An electronic device, characterized in that, The electronic device includes: Memory, used to store computer program products; A processor is configured to execute a computer program product stored in the memory, wherein, when the computer program product is executed, it implements the method described in any one of claims 1-10.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed, implement the method described in any one of claims 1-10.

Images