Micro application updating method and device, electronic equipment and program product

Abstract

The application relates to a micro application updating method and device, electronic equipment and program product, and aims to solve the technical problem that a data model is incompatible during micro application updating, causing runtime crash or user data loss. Field-level comparison is performed between a model snapshot and a second data model to generate drift information, and self-repair is performed on the difference fields based on the drift information, so that the user runtime state is seamlessly inherited, and version updating is completed without awareness. The overall process does not require user intervention, effectively avoids data loss and runtime errors, and improves the stability and user experience of micro application updating.

Description

Technical Field

[0001] This invention relates to the field of software technology, and more specifically to a micro-application update method, apparatus, electronic device, and program product. Background Technology

[0002] In modern mobile application (APP) development, micro apps, as lightweight and modular embedded functional units, are widely deployed in various APPs such as e-commerce, finance, social networking, and travel to enable rapid iteration and flexible expansion of program functions.

[0003] Traditional solutions for updating micro-applications typically rely on cold starts or static resource replacement, which can lead to the loss of user runtime state (such as form filling progress, page interaction data, component internal state, etc.) or cause runtime errors, severely impacting user experience and application stability. Summary of the Invention

[0004] One objective of this invention is to provide a micro-application update method to solve the problem of user runtime state during the micro-application update process in the prior art; a second objective is to provide a micro-application update device; a third objective is to provide an electronic device; a fourth objective is to provide a computer-readable storage medium; and a fifth objective is to provide a computer program product.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0006] A micro-application update method includes: in response to detecting an update to an older version of the micro-application, acquiring a model snapshot of a first data model and a second data model, wherein the first data model is the runtime data model of the older version of the micro-application, and the second data model is the data model of the newer version of the micro-application; generating drift information by comparing the model snapshot and the second data model, the drift information representing field-level differences between the first data model and the second data model; and performing self-healing repair on the difference fields in the first data model based on the drift information to update the older version of the micro-application to the newer version of the micro-application.

[0007] Based on the aforementioned technical methods, to address the technical issue of runtime crashes or user data loss caused by data model incompatibility during micro-application updates, a field-level comparison is performed between a model snapshot and a second data model to generate drift information. Then, self-healing repair is performed on the differing fields based on this drift information, achieving seamless inheritance of user runtime state and imperceptible version updates. The entire process requires no user intervention, effectively avoiding data loss and runtime errors, and improving the stability and user experience of micro-application updates.

[0008] Furthermore, obtaining the model snapshot of the first data model includes: calling the state serialization interface provided by the old version of the micro-application to capture a snapshot of the first data model and generate a model snapshot of the first data model; binding the model snapshot with the version number of the old version of the micro-application and storing it in a preset storage area of ​​the micro-application; and obtaining the model snapshot of the first data model by accessing the preset storage area.

[0009] Based on the above technical means, in order to solve the technical problem of repair errors caused by the chaotic relationship between snapshots and versions, the model snapshots are bound to the version identifiers and stored in an independent storage area, which achieves the effect of ensuring that the snapshot data is traceable and can be accurately matched with the corresponding version.

[0010] Furthermore, the model snapshot includes the field content of the currently displayed page of the old version of the micro-application. The step of generating drift information by comparing the model snapshot and the second data model includes: obtaining the field content of the first displayed page in the second data model, wherein the first displayed page is the updated page of the currently displayed page; comparing the field content of the first displayed page with the field content in the model snapshot to obtain the difference fields; and generating drift information based on the difference fields.

[0011] Based on the aforementioned technical methods, by limiting the comparison to the fields corresponding to the currently displayed page, the comparison range is narrowed, and the drift detection efficiency is improved. For updates to other pages not currently displayed, since they do not affect the user interface content, the data model can be updated using the traditional full update method, improving update efficiency and ultimately achieving seamless updates for the user.

[0012] Furthermore, the model snapshot includes an incremental model snapshot; the step of calling the state serialization interface provided by the old version of the micro-application to capture a snapshot of the first data model and generate a model snapshot of the first data model includes: comparing the field-level differences between the first data model and the previous model snapshot to determine the changed fields; and serializing the field values ​​and field types of the changed fields to generate a model snapshot of the first data model.

[0013] Based on the above technical means, in order to solve the technical problem of high storage overhead of full snapshots, incremental model snapshots are generated by capturing only the changed fields, which achieves the effect of reducing storage resource consumption and improving snapshot generation efficiency.

[0014] Furthermore, before binding the model snapshot with the version number of the old version of the micro-application, the method further includes: obtaining the user's page dwell time and operation frequency for the old version of the micro-application; determining the version anchoring time based on the page dwell time and the operation frequency; binding the model snapshot with the version number of the old version of the micro-application includes: binding and storing the model snapshot with the version number of the old version of the micro-application based on the version anchoring time.

[0015] Based on the above technical means, in order to solve the technical problem of incomplete data caused by fixed snapshot capture timing, the version anchor timer is dynamically adjusted in combination with user interaction behavior, which achieves the effect of ensuring the integrity of snapshot data and adapting to long-cycle interaction scenarios.

[0016] Furthermore, the drift information includes type drift information, which indicates that the field type of the first field in the first data model is different from the field type of the first field in the second data model. The step of performing self-healing repair on the differing fields in the first data model based on the drift information to update the old version of the micro-application to the new version includes: obtaining a first field value of the first field in the first data model based on the drift information, the first field value having a first field type; converting the first field value according to the second field type of the first field in the second data model to generate a second field value with a second field type; and replacing the first field value in the first data model with the second field value to update the old version of the micro-application to the new version.

[0017] Based on the above technical means, in order to solve the technical problem that data cannot be correctly loaded by the new version due to changes in field type, type conversion repair is performed on the field with type drift, thereby achieving the effect of ensuring field data compatibility.

[0018] Furthermore, the step of generating drift information by comparing the model snapshot and the second data model includes: obtaining the data model definition of the second data model from the resource package or server of the new version of the micro-application, wherein the data model definition includes the field name, field type, and field constraint corresponding to the field; comparing the model snapshot and the second data model field by field based on the data model definition to obtain the comparison result, wherein the comparison result includes at least one of missing fields, redundant fields, type drift fields, and constraint drift fields; and generating drift information based on the comparison result.

[0019] Based on the above technical means, in order to solve the technical problem of the limited coverage of drift detection types in existing technologies, multi-dimensional field-by-field comparison is performed based on a complete data model definition, which achieves the effect of comprehensively identifying four types of drift and improving the completeness of detection.

[0020] Furthermore, before performing self-healing repair on the difference fields in the first data model based on the drift information, the method further includes: obtaining change records of historical versions of the data model; extracting field type change trends, field addition / deletion trends, and constraint rule change trends based on the change records; generating a predicted drift type based on the field type change trends, field addition / deletion trends, and constraint rule change trends; and obtaining a corresponding repair strategy configuration based on the predicted drift type. The self-healing repair on the difference fields in the first data model based on the drift information includes: performing self-healing repair on the difference fields in the first data model based on the drift information and the corresponding repair strategy configuration.

[0021] Based on the above technical means, in order to solve the technical problem of long update time caused by the lag in loading the repair strategy, the drift type is predicted based on historical change trends and the repair strategy is preloaded, which achieves the effect of shortening the repair time and improving the smoothness of the update.

[0022] Furthermore, after performing self-healing repair on the difference fields in the first data model based on the drift information, the method further includes: obtaining the repaired first data model; performing an integrity check on the repaired first data model according to the data model definition of the new version of the micro-application; in response to the integrity check passing, loading the repaired first data model into the application instance of the new version of the micro-application; in response to the integrity check failing, switching the repaired first data model back to the application instance of the old version of the micro-application and reporting the abnormal information.

[0023] Based on the above technical means, in order to solve the technical problem of new version crashes caused by abnormal data after repair, integrity verification is performed on the repaired model and a failure rollback process is set up, which achieves the effect of ensuring the security of version updates and reducing operational risks.

[0024] A micro-application update device, comprising:

[0025] The acquisition module is used to acquire a model snapshot of the first data model and a second data model in response to the detection of an update to the old version of the micro-application, wherein the first data model is the runtime data model of the old version of the micro-application, and the second data model is the data model of the new version of the micro-application.

[0026] The processing module is used to generate drift information by comparing the model snapshot and the second data model, wherein the drift information characterizes the field-level differences between the first data model and the second data model;

[0027] The modification module is used to perform self-healing repair on the difference fields in the first data model based on the drift information, so as to update the old version of the micro-application to the new version of the micro-application.

[0028] Furthermore, when the acquisition module acquires the model snapshot of the first data model, it is specifically used to: call the state serialization interface provided by the old version of the micro-application to capture a snapshot of the first data model and generate a model snapshot of the first data model; bind the model snapshot with the version number of the old version of the micro-application and store it in the preset storage area of ​​the micro-application; and obtain the model snapshot of the first data model by accessing the preset storage area.

[0029] Furthermore, the model snapshot includes the field content of the currently displayed page of the old version of the micro-application. The processing module is specifically used to: obtain the field content of the first displayed page in the second data model, wherein the first displayed page is the updated page of the currently displayed page; compare the field content of the first displayed page with the field content in the model snapshot to obtain the difference fields; and generate drift information based on the difference fields.

[0030] Furthermore, the model snapshot includes an incremental model snapshot; when the acquisition module calls the state serialization interface provided by the old version of the micro-application to capture a snapshot of the first data model and generate a model snapshot of the first data model, it is specifically used to: compare the field-level differences between the first data model and the previous model snapshot to determine the changed fields; serialize the field values ​​and field types of the changed fields to generate a model snapshot of the first data model.

[0031] Furthermore, before binding the model snapshot with the version number of the old version of the micro-application, the acquisition module is also used to: acquire the user's page dwell time and operation frequency for the old version of the micro-application; determine the version anchoring time based on the page dwell time and the operation frequency; when binding the model snapshot with the version number of the old version of the micro-application, the acquisition module is specifically used to: bind and store the model snapshot with the version number of the old version of the micro-application based on the version anchoring time.

[0032] Furthermore, the drift information includes type drift information, which indicates that the field type of the first field in the first data model is different from the field type of the first field in the second data model. The modification module is specifically used to: obtain a first field value of the first field in the first data model based on the drift information, wherein the first field value has a first field type; convert the first field value according to the second field type of the first field in the second data model to generate a second field value with a second field type; and replace the first field value in the first data model with the second field value to update the old version of the micro-application to the new version of the micro-application.

[0033] Furthermore, when generating drift information by comparing the model snapshot and the second data model, the processing module specifically performs the following steps: obtaining the data model definition of the second data model from the resource package or server of the new version of the micro-application, wherein the data model definition includes the field name, field type, and field constraint corresponding to the field; comparing the model snapshot and the second data model field by field based on the data model definition to obtain the comparison result, wherein the comparison result includes at least one of missing fields, redundant fields, type drift fields, and constraint drift fields; and generating drift information based on the comparison result.

[0034] Furthermore, before performing self-healing repair on the difference fields in the first data model based on the drift information, the processing module is further configured to: obtain change records of historical versions of the data model; extract field type change trends, field addition / deletion trends, and constraint rule change trends based on the change records; generate a predicted drift type based on the field type change trends, field addition / deletion trends, and constraint rule change trends; and obtain the corresponding repair strategy configuration based on the predicted drift type. The modification module is specifically configured to: perform self-healing repair on the difference fields in the first data model based on the drift information and the corresponding repair strategy configuration.

[0035] Furthermore, after the modification module performs self-healing repair on the difference fields in the first data model based on the drift information, it is further configured to: obtain the repaired first data model; perform an integrity check on the repaired first data model according to the data model definition of the new version of the micro-application; in response to the integrity check passing, load the repaired first data model into the application instance of the new version of the micro-application; in response to the integrity check failing, switch the repaired first data model back to the application instance of the old version of the micro-application and report the abnormal information.

[0036] An electronic device includes: a memory and a processor;

[0037] The memory stores computer-executed instructions;

[0038] The processor executes the computer execution instructions stored in the memory, causing the processor to perform the microapplication update method described above.

[0039] A computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the above-described micro-application update method.

[0040] A computer program product includes a computer program that, when executed by a processor, implements the micro-application update method described above.

[0041] The beneficial effects of this invention are as follows: by comparing the model snapshot with the second data model at the field level, drift information is generated, and then self-healing repair is performed on the difference fields based on the drift information. This achieves the effect of seamless inheritance of the user's runtime state and imperceptible version update. The entire process does not require user intervention, effectively avoids data loss and runtime errors, and improves the stability of micro-application updates and user experience. Attached Figure Description

[0042] Figure 1 This is a schematic diagram illustrating a scenario for the micro-application update method provided in this embodiment.

[0043] Figure 2 Flowchart of the micro-application update method provided in this embodiment Figure 1 ;

[0044] Figure 3 Flowchart of the micro-application update method provided in this embodiment Figure 2 ;

[0045] Figure 4 This is a schematic diagram of an application interface for an update process provided in this embodiment;

[0046] Figure 5 A flowchart illustrating the specific implementation of step S207;

[0047] Figure 6 Flowchart of the micro-application update method provided in this embodiment Figure 3 ;

[0048] Figure 7 A flowchart illustrating the specific implementation of step S305;

[0049] Figure 8 This is a schematic diagram of the micro-application update device provided in this embodiment;

[0050] Figure 9This is a schematic diagram of the structure of the electronic device provided in this embodiment. Detailed Implementation

[0051] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0052] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0053] Figure 1 This is a schematic diagram illustrating a scenario for the micro-application update method provided in this embodiment. A specific application scenario for this embodiment is, for example, the version upgrade scenario of a micro-application embedded in a mobile internet app. Figure 1 As shown, APP_1, running on a terminal device (shown as a mobile phone in the diagram), embeds a micro-application M1. More specifically, APP_1 could be a vehicle control APP, while micro-application M1 could be the "Service Mall" function within APP_1. After accessing micro-application M1 through the terminal device, users can input information into the content items within micro-application M1, such as filling out forms or selecting service times. The diagram shows the user filling in the corresponding information in the "Shipping Address" field, thereby achieving the purpose of using the corresponding functional services. Micro-application M1 is a relatively independent functional unit within APP_1 and can be updated independently. For example, as shown in the diagram, after micro-application M1 is updated, its corresponding page layout and page content items may change accordingly.

[0054] Based on the above scenarios, if the micro-application needs to be updated or upgraded during the user's operation of the micro-application, the existing technology usually directly replaces the micro-application's code. However, in the above implementation method, if the data model definition (such as field types and constraint rules) of the new version of the micro-application is incompatible with the old version, directly loading the new version code may cause data loss or runtime errors during user operation, affecting user experience and application stability.

[0055] The micro-application update method provided in this embodiment obtains a model snapshot of the runtime data model of the old version of the micro-application when a micro-application update is detected, and generates drift information by comparing the model snapshot with the data model of the new version of the micro-application. Then, it performs field-level self-healing repair based on the drift information, thereby reducing the problem of user runtime data loss and version incompatibility and improving the running stability of the micro-application.

[0056] The technical solution of this embodiment and how the technical solution of this embodiment solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this embodiment will be described below with reference to the accompanying drawings. The executing subject of the micro-application update method provided in this embodiment can be an electronic device, such as a personal computer or mobile phone. The electronic device can execute the micro-application update method provided in this embodiment by executing a locally running program. During execution, it can call services, models, programs, and data deployed on external devices or cloud servers to implement one or more processing steps in the micro-application update method.

[0057] Figure 2 Flowchart of the micro-application update method provided in this embodiment Figure 1 ,like Figure 2 As shown, the method includes:

[0058] Step S101: In response to detecting an update to the old version of the micro-application, obtain a model snapshot of the first data model and a second data model, wherein the first data model is the runtime data model of the old version of the micro-application and the second data model is the data model of the new version of the micro-application.

[0059] For example, in the steps of this embodiment, the first data model is the data structure that carries business data and page status during the operation of the old version of the micro-application. For example, it is the runtime data structure that carries data such as departure date, passenger list, and selected seats filled in by the user in the ticket purchase micro-application scenario. The second data model is a data model definition predefined by the new version of the micro-application, which includes field names, field types, and field constraints. The model snapshot is a complete record obtained by serializing the current running state of the first data model.

[0060] In actual execution, for example, when a user fills out a form in the v2.0.0 version of the ticket purchase micro-application, the current runtime data structure of the micro-application is the first data model, and the predefined data structure of the v2.0.1 version to be upgraded is the second data model. During this step, for example, the micro-application management module of the host APP monitors the version update status in real time. When it receives an update notification from the server or detects that a new version resource package has been downloaded locally, it triggers the update process, subsequently obtaining a snapshot of the old version's model and the second data model of the new version.

[0061] Furthermore, obtaining the model snapshot of the first data model and the second data model can be achieved in two ways. One possible implementation uses an interface call combined with local parsing. It calls the state serialization interface provided by the older version of the microapplication to capture a runtime snapshot, while simultaneously parsing and extracting the definition content of the second data model from the locally downloaded new version resource package. Another possible implementation uses a cache read combined with server-side retrieval. It reads the pre-cached first data model snapshot from a preset storage area, while simultaneously sending a data model retrieval request to the server and receiving the second data model definition file issued by the server.

[0062] In the context of the ticketing mini-application, the complete execution process of this step is as follows: The host app detects a v2.0.1 update in the ticketing mini-application and triggers the update process; subsequently, it calls the state serialization interface of the v2.0.0 version of the ticketing mini-application to capture a snapshot of the first data model containing the departure date and passenger list data already entered by the user. Simultaneously, it parses and extracts the complete definition of the second data model from the locally downloaded v2.0.1 resource package, thus completing the acquisition of both data items. By synchronously acquiring the old version runtime model snapshot and the new version data model when the update is triggered, a data foundation is provided for subsequent compatibility comparison and repair.

[0063] Step S102: By comparing the model snapshot and the second data model, drift information is generated. The drift information represents the field-level differences between the first data model and the second data model.

[0064] For example, in this embodiment, the drift information is a summary record of the differences between the first data model and the second data model at the field dimension, used to characterize the incompatibility items between the two types of data models. In one possible implementation, the drift information is included in the drift detection report, i.e., the system generates a drift detection report containing the drift information. Field-level differences refer to differences obtained by comparing individual fields, including differences in field existence, field type, and field constraint. In the ticket purchase micro-application scenario, differences such as adding a ticket type field, deleting a selected seat field, or modifying the departure date field type in the new version will all be recorded in the drift information.

[0065] For example, in the specific execution process, the drift detection module uses the field name as the matching benchmark, compares each field in the model snapshot with the corresponding field in the second data model one by one, identifies all field-level differences, and then summarizes and generates structured drift information.

[0066] The generation of drift information through comparison can be achieved in two ways. One possible approach involves a field-by-field scanning comparison, traversing all fields of the second data model by field name, sequentially searching for corresponding fields in the model snapshot, and comparing field types, constraints, and other attributes. Differences are identified and then aggregated to generate drift information. Another possible approach uses a graph structure comparison, constructing graph structures with fields from both data models as nodes and business dependencies between fields as edges. Differences between nodes and edges are identified through graph traversal and matching to generate drift information.

[0067] In the context of the ticket purchase micro-application, the complete execution process of this step is as follows: the model snapshot of version v2.0.0 is compared field by field with the second data model of version v2.0.1 to identify three types of differences: the ticket_type field exists only in the second data model, the selected_seat field exists only in the model snapshot, and the type definitions on both sides of the departure_date field are inconsistent. These three types of differences are marked as missing fields, redundant fields, and type drift, respectively, and the original attribute and target attribute information of the corresponding fields are supplemented to generate structured drift information.

[0068] Step S103: Based on the drift information, perform self-healing repair on the difference fields in the first data model to update the old version of the micro-application to the new version of the micro-application.

[0069] For example, in this embodiment, self-healing repair refers to automatically adjusting the corresponding fields of the first data model based on the difference type of the drift information records, so that the repaired data model fully conforms to the definition requirements of the second data model. In the ticket purchase micro-application scenario, for the three types of drift identified, operations such as completing default values, filtering redundant fields, and converting field types are performed respectively, which is the specific implementation of self-healing repair. When performing this step, the repair module reads each difference record in the drift information, matches the corresponding repair strategy configuration, and performs repair operations on the difference fields in the first data model in sequence. After all fields are repaired, the version switch of the micro-application is completed.

[0070] Furthermore, regarding the self-healing repair steps, one possible implementation uses a fixed strategy for drift type matching. For missing fields, default values ​​are read from the new version's default configuration to complete the repair; for redundant fields, they are directly filtered out; for type drift, the corresponding type converter is called to perform conversion; and for constraint drift, data cleaning is performed. Another possible implementation uses a repair method optimized with user behavior data. On top of the basic repair strategy, historical user operation data is retrieved to adjust the repair results. For example, default values ​​for the ticket type field are filled in based on the user's historical ticket purchase preferences to improve the matching degree between the repair results and the user's expectations.

[0071] In the context of the ticket purchase micro-application, the complete execution process of this step is as follows: Based on the drift information, first, fill the missing ticket_type field with the default value "standard", then filter out the redundant selected_seat field, and then convert the string format of the departure_date field to the standard date format; after all fields are repaired, load the repaired data model into the new version of the micro-application instance to complete the version update.

[0072] In the above implementation, to address the technical issue of runtime crashes or user data loss due to data model incompatibility during micro-application updates, a field-level comparison is performed between the model snapshot and the second data model to generate drift information. Then, based on this drift information, self-healing repair is performed on the differing fields, achieving seamless inheritance of user runtime state and imperceptible version updates. The entire process requires no user intervention, effectively avoiding data loss and runtime errors, and improving the stability and user experience of micro-application updates.

[0073] Figure 3 Flowchart of the micro-application update method provided in this embodiment Figure 2 ,like Figure 3 As shown, in this embodiment... Figure 2 Based on the embodiment, step S101 is further refined, including:

[0074] Step S201: In response to the detection of an update to the old version of the micro-application, the state serialization interface provided by the old version of the micro-application is called to capture a snapshot of the first data model and generate a model snapshot of the first data model.

[0075] Step S202: Bind the model snapshot to the version number of the old version of the micro-application and store it in the micro-application's preset storage area.

[0076] For example, in this embodiment, the preset storage area is an independent storage area within the host APP specifically used to host micro-application snapshot data and intermediate state data. It possesses data isolation, ensuring the security of micro-application data. Version number binding refers to establishing an association mapping relationship between snapshot data and the corresponding micro-application version identifier. For instance, in the ticket purchasing micro-application scenario, the model snapshot of version v2.0.0 of the ticket purchasing micro-application is associated with the version number "v2.0.0" and stored in the host APP's dedicated storage directory; this is the specific implementation of version number binding and storage. During this step, after the model snapshot is generated, a version number metadata tag is added to the snapshot data to establish a mapping relationship between the snapshot and the version. Then, the tagged snapshot data is written to the preset storage area to complete persistent storage.

[0077] Furthermore, snapshot binding and storage can be implemented in two ways. In one possible implementation, a direct version number binding method is used, where the semantic version number of the microapplication is stored along with the snapshot's metadata, and the corresponding snapshot is directly matched by the version number when reading. In another possible implementation, a resource package hash binding method is used, where the hash value of the new version resource package is calculated, and the hash value is used as a binding identifier associated with the snapshot for storage, avoiding matching errors caused by duplicate or conflicting version numbers.

[0078] The steps of the above embodiment will be explained below with a more specific application scenario. For example, firstly, for the model snapshot of the v2.0.0 version ticketing micro-application, the version number "v2.0.0" is written into the metadata field of the snapshot data, and the SHA-256 hash value of the corresponding v2.0.1 version resource package (including the second data model) is also written to establish a mapping relationship between the model snapshot and the second data model; then, the snapshot data is written to the micro-application hosting storage directory of the host APP to complete the binding and storage. In the above implementation method, in order to solve the technical problem of repair errors caused by the chaotic relationship between snapshots and versions, by binding the model snapshot with the version identifier and storing it in an independent storage area, the effect of ensuring that the snapshot data is traceable and can be accurately matched with the corresponding version is achieved.

[0079] Step S203: Obtain a model snapshot of the first data model by accessing a preset storage area, wherein the model snapshot includes the field content of the currently displayed page of the old version of the micro-application.

[0080] Step S204: Obtain the field content of the first display page in the second data model. The first display page is the updated page of the current display page.

[0081] Step S205: Compare the field content of the first display page with the field content of the model snapshot field by field to obtain the difference fields.

[0082] For example, in this embodiment, the first display page is the business page in the new version of the micro-application that corresponds to the currently displayed page in the old version. For instance, if the old version currently displays a ticket purchase form page, then the first display page is the ticket purchase form page corresponding to the new version. The difference fields are fields in the data models corresponding to the two pages where the attributes do not match. More specifically, for example, in the ticket purchase micro-application scenario, the ticket purchase form page currently displayed in the old version includes departure date, passenger, and selected seat fields, while the corresponding ticket purchase form page in the new version includes departure date, passenger, and ticket type fields. The selected seat and ticket type fields are the difference fields. When performing this step, based on the correspondence between the pages, all fields of both sides of the page are extracted, and the field types, constraints, and other attributes are matched and compared one by one according to the field name. Fields with inconsistent attributes or existing only on one side are filtered out as difference fields. For other non-currently displayed pages, i.e., the second display page (e.g., the refund page), the model data can be fully updated using traditional methods, thereby improving update efficiency.

[0083] Page-level field comparison can be achieved in two ways. One possible approach is to use exact field name matching, where the field name is used as a unique identifier for one-to-one correspondence, and then the field type and constraint attributes are compared to filter out discrepancies. Another possible approach is to use page element mapping, where the unique identifier of the page component is used to match the corresponding data field, and then attribute comparison is performed. This approach is suitable for scenarios where field names may change.

[0084] In the context of a ticketing micro-application, the complete execution process of this step is as follows: Extract the `departure_date`, `passenger_list`, and `selected_seat` fields from the current ticketing form page in the model snapshot, and the `departure_date`, `passenger_list`, and `ticket_type` fields from the corresponding ticketing form page in the second data model; after comparing each field, `selected_seat` and `ticket_type` are identified as the difference fields, and the `departure_date` field is marked as having a type difference. In the above implementation, to solve the technical problem of high overhead and low efficiency in comparing the entire data model, the comparison is limited to the fields corresponding to the currently displayed page, thus narrowing the comparison range and improving the drift detection efficiency. For updates to other pages that are not currently displayed, since they do not affect the content of the user interface, the data model can be updated using the traditional full update method, improving update efficiency and ultimately achieving seamless updates for the user.

[0085] Step S206: Generate drift information based on the difference field.

[0086] Step S207: Based on the drift information, perform self-healing repair on the difference fields in the first data model to update the old version of the micro-application to the new version of the micro-application.

[0087] For example, the self-healing repair in this step targets the difference fields corresponding to the currently displayed page. After the repair is completed, the page-level version switch can be completed, ensuring the continuity of the user's current operation page state. Taking the ticket purchase micro-application scenario as an example, after identifying the difference fields, after repairing the difference fields of the ticket purchase form page, the form content currently filled in by the user can be directly displayed and operated normally in the new version page. When performing this step, according to the difference field type in the page-level drift information, the corresponding repair strategy is matched, and the difference fields of the current page are repaired sequentially. After the repair is completed, the page data is switched to the page object of the new version of the micro-application.

[0088] Among them, the self-healing repair method at the page level can be implemented in several ways. For example, a single-page synchronous repair method can be used, which only repairs the difference fields of the currently displayed page, and the data of other pages can be processed when the user visits, reducing the real-time computing power overhead. Another example is the full-page background repair method, which repairs the data model of other pages asynchronously in the background while repairing the current page, improving the smoothness of the user's subsequent access to other pages.

[0089] In a more specific application scenario, the above steps are executed as follows: For the differing fields on the ticket purchase form page, the default value of the `ticket_type` field is filled in, the `selected_seat` field is filtered, and the format of the `departure_date` field is converted. After all repairs are completed, the page data is loaded into the new version of the ticket purchase form page object. Users can continue to fill in information on the new version page, and the previously filled information is retained without needing to re-enter the data. In the above implementation method, in order to solve the technical problem of losing the user's current page state during updates, self-healing repair is performed on the differing fields of the currently displayed page, achieving the effect of ensuring the continuity of user operations and realizing seamless page updates.

[0090] Figure 4 This is a schematic diagram of an application interface for an update process provided in this embodiment, such as... Figure 4As shown, within the host app's application interface, the first display page of the micro-application M1 is displayed. This first display page, for example, is a ticket purchase page, which includes input controls for "departure point," "destination," and "travel date." After the user completes the input of the "departure point" and "destination" (represented by "XX" and "XXX" in the diagram), the system detects that a new version of the old micro-application M1_1 exists. The system then performs self-healing repair on the first data model of the old version of micro-application M1_1 through the steps described above. Afterward, the old version of micro-application M1_1 is updated to the new version, M1_2. A "return ticket" input control has been added to the first display page, but the information already entered in the "departure point" and "destination" controls is still retained on this first display page. This ensures that the previously entered information is preserved without requiring re-entry, achieving a seamless update for the user.

[0091] Furthermore, in one possible implementation, the model snapshot includes an incremental model snapshot, and the specific implementation of step S201 includes:

[0092] Step S2011: Compare the field-level differences between the first data model and the previous model snapshot to determine the changed fields.

[0093] Step S2012: Serialize the field values ​​and field types of the changed fields to generate a model snapshot of the first data model.

[0094] For example, in this step, the incremental model snapshot is a specific implementation of the model snapshot. Specifically, the incremental model snapshot is a snapshot that only records the field data that has changed relative to the previous snapshot, as opposed to a full snapshot that includes all fields; the changed fields are those whose field values ​​or field attributes have changed relative to the previous snapshot. In the ticket purchase micro-application scenario, if the user only modifies the departure date field and the other fields remain unchanged, then the incremental snapshot only contains the relevant data for the departure date field. When performing this step, firstly, each field of the current first data model is compared with the corresponding field of the previous version of the model snapshot to filter out the fields whose values ​​or attributes have changed; then, only these changed fields are serialized to generate an incremental model snapshot.

[0095] Furthermore, in one possible implementation, a field value hash comparison method is used to calculate the hash value of each field. By comparing the hash value of the current field with the corresponding field in the previous snapshot, it is possible to quickly determine whether the field has changed and filter out the changed fields. In another possible implementation, an event listening method is used to listen for field modification events in the data model and directly record the modified field information without performing a full field comparison.

[0096] In the context of the ticket purchase micro-application, the complete execution process of this step is as follows: When the user modifies the value of the departure date field in the ticket purchase micro-application, the system compares the hash values ​​of each field in the current data model with the hash values ​​of the previous snapshot one by one to determine that only the departure_date field has changed; then the field value and field type of this field are serialized to generate an incremental model snapshot containing only this field.

[0097] In the above implementation, in order to solve the technical problem of large storage overhead of full snapshots, incremental model snapshots are generated by capturing only the changed fields, which achieves the effect of reducing storage resource consumption and improving snapshot generation efficiency.

[0098] Furthermore, in one possible implementation, prior to step S202, the following steps are also included:

[0099] Step S201A-1: Obtain the user's page dwell time and operation frequency for the old version of the micro-application.

[0100] Step S201A-2: Determine the version anchor timer based on page dwell time and operation frequency.

[0101] In performing the above steps, the specific implementation of step S202 includes:

[0102] Step S202A: Based on the version anchoring timer, bind the model snapshot with the version number of the old version of the micro-application and store it in the micro-application's preset storage area.

[0103] For example, the version anchoring timer refers to the point in time when the snapshot and version number binding operation is performed, the page dwell time is the continuous time the user stays on the current micro-application page, and the operation frequency is the number of times the user performs clicks, inputs, etc., per unit time. Taking the ticket purchase micro-application scenario as an example, anchoring is not performed while the user is continuously filling in information on the ticket purchase form page. The binding is performed only when the user pauses the operation, which ensures the integrity of the snapshot data. In the specific execution process, by collecting the user's interaction behavior data in the micro-application in real time, the page dwell time and operation frequency are calculated, and the stable state of the user's operation is identified based on preset judgment rules. The time point corresponding to the stable state is determined as the version anchoring timer; then, after reaching the anchoring timer, the snapshot and version number binding storage is performed.

[0104] The version anchoring timing can be determined in two ways. One possible approach is to use an operation frequency threshold judgment method. When the user's operation frequency is detected to be lower than a preset threshold for a certain period of time, the user's operation is determined to be in a stable state, and version anchoring is triggered. Another possible approach is to use an operation node matching method. Key operation nodes such as the user completing a single-step form filling or clicking the next step are identified, and version anchoring is triggered at the node.

[0105] The following section provides a more detailed explanation of the above implementation process using a ticket purchasing micro-application scenario: During the process of filling out the ticket purchase form, the system detects that the user's operation frequency is high and they are in a continuous input state, so version anchoring is not executed temporarily. When the user finishes filling in the passenger information and pauses the operation, the system detects that the operation frequency is below a preset threshold for 3 seconds, determining that the version anchoring timer has been reached. At this point, the snapshot and version number binding storage are executed. In the above implementation method, to solve the technical problem of incomplete data caused by a fixed snapshot capture timing, the version anchoring timer is dynamically adjusted based on user interaction behavior, achieving the effect of ensuring snapshot data integrity and adapting to long-cycle interaction scenarios.

[0106] Furthermore, in one possible implementation, the drift information includes type drift information, which indicates that the field type of the first field in the first data model is different from the field type of the first field in the second data model. For example... Figure 5 As shown, the specific implementation of step S207 includes:

[0107] Step S2071: Based on the drift information, obtain the first field value of the first field in the first data model, wherein the first field value has the first field type.

[0108] Step S2072: Based on the second field type of the first field in the second data model, convert the value of the first field to generate a second field value with the second field type.

[0109] Step S2073: Replace the first field value in the first data model with the second field value to update the old version of the microapplication to the new version of the microapplication.

[0110] For example, in this step, the first field is the field with type drift, that is, the field name is the same in the old and new versions but the field type is different; the first field type is the data type of the field in the old version, and the second field type is the data type of the field in the new version. In the ticket purchase micro-application scenario, the departure_date field is a string type in the old version and a date type in the new version, and this field is the first field. When performing this step, the first field corresponding to the type drift is located from the drift information, and the first field value and first field type of this field in the first data model are read; the corresponding type conversion rule is matched to convert the first field value to the second field value corresponding to the second field type; the original field value is replaced with the second field value to complete the type repair of this field.

[0111] Type drift correction can be implemented in two ways. One possible approach is to use format truncation conversion, which is used for scenarios where type conversion can be achieved by adjusting the format. It directly extracts the valid part of the field value to complete the conversion, such as extracting the date part from a date string with time. Another possible approach is to use regular expression parsing conversion, which matches the valid content of the field value with regular expressions, parses it, and converts it to the target type. This is suitable for field values ​​with inconsistent formats.

[0112] In the context of the ticketing micro-application, the complete execution process of this step is as follows: Addressing the type drift of the `departure_date` field, the string value "2025-12-2514:30:00" from the old version is read. A format truncation conversion method is used to extract the date portion, resulting in "2025-12-25". This is then converted to a standard date type field value and replaced with the original field value, completing the type repair for this field. In the above implementation, to resolve the technical issue of data not being correctly loaded by the new version due to field type changes, type conversion repair is performed on the type-drifted field, thus ensuring data compatibility.

[0113] In summary, this embodiment... Figure 2 The embodiment shown provides a basic update process, which is further refined with details such as snapshot capture, page-level comparison, incremental snapshot, dynamic anchoring, and type drift repair. It can adapt to the update needs of different interaction scenarios, and while ensuring the continuity of user status, it further improves update efficiency and data integrity, and optimizes the user experience of hot updates for micro-applications.

[0114] Figure 6 Flowchart of the micro-application update method provided in this embodiment Figure 3 ,like Figure 6 As shown, in this embodiment... Figure 2 Based on the embodiment, step S102 is further refined, including:

[0115] Step S301: In response to detecting an update to the old version of the micro-application, obtain a model snapshot of the first data model and a second data model, wherein the first data model is the runtime data model of the old version of the micro-application and the second data model is the data model of the new version of the micro-application.

[0116] The specific implementation of step S301 has been described in detail in previous embodiments, and can be found in the following references. Figure 2 , Figure 3 The details of the corresponding embodiments will not be repeated here.

[0117] Step S302: Obtain the data model definition of the second data model from the resource package or server of the new version of the micro-application. The data model definition includes the field name, field type and field constraint corresponding to the field.

[0118] Step S303: Based on the data model definition, perform a field-by-field comparison between the model snapshot and the second data model to obtain the comparison results. The comparison results include at least one of the following: missing fields, redundant fields, type drift fields, and constraint drift fields.

[0119] Step S304: Generate drift information based on the comparison results.

[0120] For example, in this step, the data model is defined as a structured description file of the new version data model, containing complete attributes such as field name, field type, and field constraints for each field. Constraint drift fields are fields whose names exist but whose constraint rules have changed. These constraint rules include requirements such as mandatory fields, value ranges, and formatting requirements. In the ticketing micro-application scenario, the new version adds a mandatory constraint to the `ticket_type` field; this field is a constraint drift field. When performing this step, first, the complete data model definition file of the new version is obtained; then, using this definition as a benchmark, it is compared one by one with all fields of the model snapshot to identify four types of comparison results: missing fields, redundant fields, type drift fields, and constraint drift fields; finally, the comparison results are structured and organized according to category to generate complete drift information. Regarding the specific implementation process of generating drift information through full field comparison, one possible implementation is to use a local resource package parsing method, which parses the built-in model definition file from the downloaded new version of the micro-application resource package, performs field-by-field comparison locally, and generates drift information. Another possible implementation is to use a server-side comparison method, which uploads the model snapshot to the server, and the server returns structured drift information after completing the full field comparison. This method is suitable for scenarios with limited terminal computing power.

[0121] In the context of the ticket purchasing micro-application, the complete execution process of this step is as follows: Parse the data model definition from the resource package of the ticket purchasing micro-application version 2.0.1, including the names, types, and constraint rules of fields such as departure_date, passenger_list, and ticket_type; compare it field by field with the model snapshot of version 2.0.0 to obtain three types of comparison results: missing field ticket_type, redundant field selected_seat, and type-drifted field departure_date; organize the above results according to the structure of field name, drift type, original attribute, and target attribute to generate structured drift information.

[0122] In the above implementation method, in order to solve the technical problem of the limited coverage of drift detection types in the existing technology, multi-dimensional field-by-field comparison is performed based on a complete data model definition, which achieves the effect of comprehensively identifying four types of drift and improving the completeness of detection.

[0123] Furthermore, this embodiment also includes:

[0124] Step S305: Obtain the repair strategy configuration.

[0125] Specifically, such as Figure 7 As shown, the specific implementation steps of step S305 include:

[0126] Step S3051: Obtain the change records of the historical version data model, and extract the field type change trend, field addition / deletion trend, and constraint rule change trend based on the change records.

[0127] Step S3052: Generate the prediction drift type based on the field type change trend, field addition / deletion trend, and constraint rule change trend.

[0128] Step S3053: Obtain the corresponding repair strategy configuration based on the predicted drift type.

[0129] For example, in the steps of this embodiment, the change record of the historical version data model is the historical log of data model adjustments in previous versions of the micro-application, including information such as field additions and deletions, type adjustments, and constraint changes in each version; the predicted drift type is the drift type that may occur in the current version (i.e., the old version of the micro-application, corresponding to the runtime data model) inferred based on historical change patterns; the repair strategy configuration is the repair rules, conversion tools, and other pre-requisite resources corresponding to various types of drift. For example, in the ticket purchase micro-application scenario, based on the record of continuous format adjustments of the departure_date field in the three historical versions, it is predicted that the current version may experience type drift of this field, and the corresponding date type converter is loaded in advance, thereby realizing the prediction and preloading of the repair strategy configuration.

[0130] Furthermore, in executing this step, the historical version change records of the micro-application are first retrieved to extract the change patterns of various fields. Then, based on these change patterns, the drift trend of each field is analyzed to generate the predicted drift type for the current version. Finally, the corresponding repair strategy configuration is retrieved in advance based on the prediction results to complete resource preloading. The prediction of drift types and retrieval of repair strategy configurations can be achieved in at least two ways. One possible implementation uses frequency statistical prediction, statistically analyzing the frequency and type of historical changes for each field, using the field types with high-frequency changes as the predicted drift types, and retrieving the corresponding repair strategies. Another possible implementation uses version-related prediction, combining the business planning of version iterations to predict the drift type of corresponding fields based on the content of functional upgrades; this is suitable for scenarios with clear version planning.

[0131] In the context of the ticket purchase micro-application, the execution process of the steps in the above embodiment includes: retrieving the model change records of the ticket purchase micro-application for the past three versions, and statistically finding that the departure_date field has adjusted its format in each version, while the ticket_type field is a frequently added field in the business; then, based on this, predicting that the current version has drifting departure_date type and newly added drifting types in the ticket_type field, and preloading repair strategy configurations such as date format converter and ticket type default value configuration.

[0132] In the above implementation, in order to solve the technical problem of long update time caused by the lag in loading the repair strategy, the drift type is predicted based on the historical change trend and the repair strategy is preloaded, which achieves the effect of shortening the repair time and improving the smoothness of the update.

[0133] Step S306: Based on the drift information and the corresponding repair strategy configuration, perform self-healing repair on the difference fields in the first data model.

[0134] For example, the self-healing repair in the steps is executed based on pre-loaded repair strategy configurations. During the repair process, pre-prepared conversion tools, default value configurations, and other resources can be directly invoked without temporary loading. Specifically, for example, in a ticket purchase micro-application scenario, for predicted type drift, the pre-loaded date converter can be directly invoked to perform the conversion, which can improve repair efficiency. In the specific execution process, each difference in the drift information is first read, and the corresponding pre-loaded repair strategy configuration is matched. Then, repair operations are performed on each difference field in sequence. By combining the self-healing repair with pre-loaded repair strategy configurations, the effect of improving repair efficiency and reducing user waiting time can be achieved.

[0135] Furthermore, in one possible implementation, step S306 employs a hierarchical self-healing repair method to perform self-healing repair on the discrepancy fields in the first data model. Specifically, for example, the engine responsible for performing self-healing repair reads the drift detection report, obtains the drift type from the drift information, and performs differentiated automatic repair, including:

[0136] Missing field repair: For fields that exist in the new version but are missing in the old version snapshot, the self-healing engine reads the default value of the field from the default configuration file of the new version and completes it; if there is no default configuration, the system-level default value is automatically filled according to the nullability constraint of the field, or it is calculated and filled according to the user's historical behavior data.

[0137] Redundant field repair: Fields that existed in the old version snapshot but are obsolete in the new version data model are actively filtered and removed by the self-healing engine during the migration process to avoid data redundancy or structural conflicts.

[0138] Type drift field repair: When the types of fields with the same name are incompatible between the old and new versions, the self-healing engine calls the type converter to perform automatic type conversion. If the conversion fails, the field is downgraded to the default value of the new version, and the conversion exception is logged without interrupting the overall migration process.

[0139] Constraint drift field repair: When constraints such as field requirement change, the self-healing engine performs data cleaning. If the new version requires a field to be filled while the old version had an empty field value, a data completion process is triggered; if the old version contains data that violates the uniqueness constraint of the new version, duplicate data is removed or conflicting data is marked according to the user-selected strategy.

[0140] Once self-healing is complete, the self-healing engine outputs a fully repaired data model that is fully compatible with the updated version's data model definition and can be safely loaded into the new version of the microapplication instance as input data.

[0141] Further, optionally, after step S306, the method further includes:

[0142] Step S307: Obtain the repaired first data model.

[0143] Step S308: Perform an integrity check on the repaired first data model according to the data model definition of the new version of the micro-application.

[0144] Step S309: In response to the integrity verification passing, load the repaired first data model into the application instance of the new version of the micro-application to update the old version of the micro-application to the new version of the micro-application.

[0145] Step S310: In response to the failure of the integrity check, the repaired first data model is switched back to the application instance of the old version of the micro-application, and the abnormal information is reported.

[0146] For example, the steps in the above embodiment are a process of further performing integrity verification on the repaired first data model after generating it. Specifically, in this embodiment, integrity verification refers to the process of checking whether the repaired data model fully conforms to the definition of the new version; rollback is the operation of restoring the old version of the micro-application to its running state when verification fails. For example, in the ticket purchase micro-application scenario, rollback means that if the repaired data model has fields with non-compliant formats, it will roll back to the old version to continue running, avoiding crashes. When executing the steps in this embodiment, firstly, the complete repaired data model (i.e., the repaired first data model) is obtained after the repair is completed; then, based on the definition of the new version data model (second data model), the types and constraints of all fields in the repaired data model are verified to meet the requirements; if the verification passes, the data is loaded into the new version instance to complete the update; if the verification fails, the old version running state is restored and the exception information is reported.

[0147] Regarding the integrity verification process, one possible implementation is a single-level rule verification method, which only verifies whether basic rules such as field type and mandatory fields conform to the new version definition. Another possible implementation is a multi-level verification method, which sequentially executes rule verification, business semantic verification, and runtime stability verification. Rule verification verifies field type and mandatory fields, semantic verification verifies whether field values ​​conform to business logic, and stability verification combines runtime data to verify data availability, thus ensuring the security of the repaired model from multiple dimensions.

[0148] The following section will further explain the above steps using the ticketing micro-application scenario. For example, after the ticketing micro-application is repaired, rule validation is first performed to verify that the types and constraints of each field conform to the new version definition; then, business semantic validation is performed to confirm that the departure date is later than the current date and that the passenger list is not empty; after the validation passes, the repaired data is loaded into the new version micro-application instance to complete the update; if date conversion failure is found during validation, the system switches back to the old version and reports the date type conversion exception.

[0149] In the above implementation method, in order to solve the technical problem that the new version crashes due to abnormal data after repair, the integrity verification of the repaired model is performed and a failure rollback process is set up, which achieves the effect of ensuring the security of version updates and reducing operational risks.

[0150] This embodiment improves the processes of full drift detection, drift prediction preloading, multi-layer verification and anomaly rollback, forming a complete closed loop of "detection, prediction, repair, verification and rollback", which can comprehensively cover various data model drift scenarios. While ensuring update efficiency, it significantly improves the stability and security of micro-application hot updates.

[0151] Figure 8 This is a schematic diagram of the micro-application update device provided in this embodiment, as shown below. Figure 8 As shown, the micro-application update device 40 provided in this embodiment includes:

[0152] The acquisition module 401 is used to acquire a model snapshot of the first data model and a second data model in response to the detection of an update to the old version of the micro-application. The first data model is the runtime data model of the old version of the micro-application, and the second data model is the data model of the new version of the micro-application.

[0153] Processing module 402 is used to generate drift information by comparing model snapshots and the second data model. The drift information represents the field-level differences between the first data model and the second data model.

[0154] Modify module 403 to perform self-healing repair on the difference fields in the first data model based on drift information, so as to update the old version of the microapplication to the new version of the microapplication.

[0155] In one possible implementation,

[0156] When obtaining the model snapshot of the first data model, the acquisition module 401 is specifically used to: call the state serialization interface provided by the old version of the micro-application to capture a snapshot of the first data model and generate a model snapshot of the first data model; bind the model snapshot with the version number of the old version of the micro-application and store it in the preset storage area of ​​the micro-application; and obtain the model snapshot of the first data model by accessing the preset storage area.

[0157] In one possible implementation, the model snapshot includes the field content of the current display page of the old version of the micro-application. The processing module 402 is specifically used to: obtain the field content of the first display page in the second data model, where the first display page is the updated version of the current display page; compare the field content of the first display page with the field content in the model snapshot to obtain the difference fields; and generate drift information based on the difference fields.

[0158] In one possible implementation, the model snapshot includes an incremental model snapshot; when the acquisition module 401 calls the state serialization interface provided by the old version of the micro-application to capture a snapshot of the first data model and generate a model snapshot of the first data model, it is specifically used to: compare the field-level differences between the first data model and the previous model snapshot to determine the changed fields; serialize the field values ​​and field types of the changed fields to generate a model snapshot of the first data model.

[0159] In one possible implementation, before binding the model snapshot with the version number of the old version of the micro-application, the acquisition module 401 is further configured to: acquire the user's page dwell time and operation frequency for the old version of the micro-application; determine the version anchor timer based on the page dwell time and operation frequency; when binding the model snapshot with the version number of the old version of the micro-application, the acquisition module 401 is specifically configured to: bind and store the model snapshot with the version number of the old version of the micro-application based on the version anchor timer.

[0160] In one possible implementation, the drift information includes type drift information, which indicates a first field in a first data model whose field type is different from that of a first field in a second data model. Modification module 403 is specifically used to: obtain a first field value of the first field in the first data model based on the drift information, the first field value having a first field type; convert the first field value according to the second field type of the first field in the second data model to generate a second field value with the second field type; and replace the first field value in the first data model with the second field value to update the old version of the micro-application to a new version.

[0161] In one possible implementation, when the processing module 402 generates drift information by comparing the model snapshot and the second data model, it specifically performs the following steps: obtaining the data model definition of the second data model from the resource package or server of the new version of the micro-application, wherein the data model definition includes the field name, field type and field constraint corresponding to the field; comparing the model snapshot and the second data model field by field based on the data model definition to obtain the comparison result, wherein the comparison result includes at least one of missing field, redundant field, type drift field and constraint drift field; and generating drift information based on the comparison result.

[0162] In one possible implementation, before processing module 402 performs self-healing repair on the difference fields in the first data model based on drift information, it is further configured to: obtain change records of historical versions of the data model; extract field type change trends, field addition / deletion trends, and constraint rule change trends based on the change records; generate predicted drift types based on the field type change trends, field addition / deletion trends, and constraint rule change trends; and obtain the corresponding repair strategy configuration based on the predicted drift type. Modification module 403 is specifically configured to: perform self-healing repair on the difference fields in the first data model based on drift information and the corresponding repair strategy configuration.

[0163] In one possible implementation, after modifying the module 403 performs self-healing repair on the difference fields in the first data model based on the drift information, it is further configured to: obtain the repaired first data model; perform integrity verification on the repaired first data model according to the data model definition of the new version of the micro-application; in response to the integrity verification passing, load the repaired first data model into the application instance of the new version of the micro-application; in response to the integrity verification failing, switch the repaired first data model back to the application instance of the old version of the micro-application and report the exception information.

[0164] The micro-application update device 40 provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0165] Figure 9 This is a schematic diagram of the structure of the electronic device provided in this embodiment. Figure 9 As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0166] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0167] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0168] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0169] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0170] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings of this embodiment are not limited to only one bus or one type of bus.

[0171] This embodiment also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0172] This embodiment also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0173] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0174] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0175] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0176] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0177] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0178] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory, magnetic disks, or optical disks.

[0179] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0180] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

[0181] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A micro-application update method, characterized in that, include: In response to detecting an update to an older version of the micro-application, a model snapshot of a first data model and a second data model are obtained, wherein the first data model is the runtime data model of the older version of the micro-application, and the second data model is the data model of the new version of the micro-application. By comparing the model snapshot and the second data model, drift information is generated, which characterizes the field-level differences between the first data model and the second data model. Based on the drift information, the difference fields in the first data model are self-healed to update the old version of the micro-application to the new version.

2. The method according to claim 1, characterized in that, The step of obtaining a model snapshot of the first data model includes: Call the state serialization interface provided by the old version of the micro-application to capture a snapshot of the first data model and generate a model snapshot of the first data model; The model snapshot is bound to the version number of the old version of the micro-application and stored in the micro-application's preset storage area. A snapshot of the first data model is obtained by accessing the preset storage area.

3. The method according to claim 2, characterized in that, The model snapshot includes field content of the currently displayed page of the old version of the micro-application. The step of generating drift information by comparing the model snapshot with the second data model includes: Obtain the field content of the first display page in the second data model, where the first display page is the updated version of the current display page; The difference fields are obtained by comparing the field content of the first displayed page with the field content of the model snapshot field by field; Drift information is generated based on the difference field.

4. The method according to claim 2, characterized in that, The model snapshot includes an incremental model snapshot; the step of calling the state serialization interface provided by the old version of the micro-application to capture a snapshot of the first data model and generate a model snapshot of the first data model includes: Compare the field-level differences between the first data model and the snapshot of the previous model to identify the changed fields; The field values ​​and field types of the changed fields are serialized to generate a model snapshot of the first data model.

5. The method according to claim 2, characterized in that, Before binding the model snapshot to the version number of the older micro-application, the method further includes: Obtain the user's page dwell time and operation frequency for the old version of the micro-application; The version anchor timer is determined based on the page dwell time and the operation frequency. The step of binding the model snapshot with the version number of the old version of the micro-application includes: Based on the version anchoring timer, the model snapshot is bound and stored with the version number of the old version micro-application.

6. The method according to claim 1, characterized in that, The drift information includes type drift information, which is used to indicate a first field in the first data model, wherein the field type of the first field in the first data model is different from the field type of the first field in the second data model. The step of performing self-healing repair on the difference fields in the first data model based on the drift information to update the old version of the micro-application to the new version includes: Based on the drift information, the first field value of the first field in the first data model is obtained, and the first field value has a first field type; Based on the second field type of the first field in the second data model, the value of the first field is converted to generate a second field value with the second field type. The old version of the micro-application is updated to the new version of the micro-application by replacing the first field value in the first data model with the second field value.

7. The method according to claim 1, characterized in that, The step of generating drift information by comparing the model snapshot and the second data model includes: Obtain the data model definition of the second data model from the resource package or server of the new version of the micro-application. The data model definition includes the field name, field type and field constraint corresponding to the field. Based on the data model definition, the model snapshot and the second data model are compared field by field to obtain the comparison result. The comparison result includes at least one of missing fields, redundant fields, type drift fields, and constraint drift fields. Based on the comparison results, drift information is generated.

8. The method according to claim 1, characterized in that, Before performing self-healing repair on the difference fields in the first data model based on the drift information, the method further includes: Obtain the change records of the historical version data model, and extract the field type change trend, field addition / deletion trend, and constraint rule change trend based on the change records; Based on the field type change trend, the field addition / deletion trend, and the constraint rule change trend, generate the predicted drift type; Based on the predicted drift type, obtain the corresponding repair strategy configuration; The self-healing repair of the difference fields in the first data model based on the drift information includes: Based on the drift information and the corresponding repair strategy configuration, the difference fields in the first data model are self-healed and repaired.

9. The method according to claim 1, characterized in that, After performing self-healing repair on the difference fields in the first data model based on the drift information, the method further includes: Obtain the repaired first data model; Based on the data model definition of the new version of the micro-application, perform an integrity check on the repaired first data model; In response to the integrity verification passing, the repaired first data model is loaded into the application instance of the new version of the micro-application; In response to the failure of the integrity check, the repaired first data model is switched back to the application instance of the old version of the micro-application, and the abnormal information is reported.

10. A micro-application update device, characterized in that, include: The acquisition module is used to acquire a model snapshot of the first data model and a second data model in response to the detection of an update to the old version of the micro-application, wherein the first data model is the runtime data model of the old version of the micro-application, and the second data model is the data model of the new version of the micro-application. The processing module is used to generate drift information by comparing the model snapshot and the second data model, wherein the drift information characterizes the field-level differences between the first data model and the second data model; The modification module is used to perform self-healing repair on the difference fields in the first data model based on the drift information, so as to update the old version of the micro-application to the new version of the micro-application.

11. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-9.

12. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-9.

Images