Multi-dimensional view object copying and synchronizing method based on low-code platform

Abstract

The invention provides a multi-dimensional view object copying and synchronizing method based on a low-code platform, and belongs to the technical field of software development and data management, and the method comprises the following steps: carrying out dimension level judgment on dimension information to confirm target dimension information, and collecting source view object metadata based on the target dimension information; performing conflict check on the target dimension information and the source view object metadata to obtain a pre-check result; and according to the pre-check result, the source view object metadata and the change increment, performing increment copying and synchronous processing to obtain extended view object metadata and a mapping relationship.

Description

Technical Field

[0001] This application belongs to the technical field of software development and data management, and particularly relates to a multi-dimensional view object replication and synchronization method based on a low-code platform. Background Art

[0002] With the continuous improvement of the complexity of enterprise-level application systems, especially in the context of the widespread application of low-code development platforms, the metadata management between view objects (VO) and business entities (BE) has become an important part of system development and maintenance. In the actual development process, users often need to copy the view object structure under a certain dimension to another dimension, for example, copy the card dimension in a form to the list dimension, to achieve interface layout reuse or function expansion.

[0003] The traditional approach usually involves full-copying the entire view object structure and manually adjusting fields, nodes, and mapping relationships. Although this method is simple and direct, it has obvious drawbacks in practical applications: on the one hand, full-copying is inefficient, especially when the metadata volume is large and the structure is complex; on the other hand, it is prone to problems such as field name conflicts, node duplicates, and BE mapping errors, which may lead to system operation anomalies or function failures. In addition, the existing technology lacks an effective verification mechanism for the existing metadata in the target dimension and cannot identify potential conflicts before copying, increasing the workload of later debugging and repair. Summary of the Invention

[0004] To solve at least one aspect of the technical problems in the background art, this application provides a multi-dimensional view object replication and synchronization method based on a low-code platform.

[0005] The technical solution adopted in this application is as follows: The first aspect embodiment of this application provides a multi-dimensional view object replication and synchronization method based on a low-code platform, including: Judging the dimension level of the dimension information to confirm the target dimension information, and collecting the source view object metadata based on the target dimension information; Checking for conflicts between the target dimension information and the source view object metadata to obtain a pre-check result; Performing incremental replication and synchronization processing based on the pre-check result, the source view object metadata, and the change increment to obtain the extended view object metadata and the mapping relationship.

[0006] According to an embodiment of this application, the judging the dimension level of the dimension information to confirm the target dimension information, and collecting the source view object metadata based on the target dimension information is specifically: The current dimension level will be determined according to the dimension information to obtain the target dimension information; The dimension information is information of a specific dimension level, and the target dimension information is information of the target dimension to which it is currently to be copied; The source view object metadata is all the extended fields and node information of the information of the target dimension to which it is currently to be copied.

[0007] According to an embodiment of the present application, the conflict check includes: existence check of view object metadata and existence check of business entity metadata.

[0008] According to an embodiment of the present application, the existence check of the view object metadata is specifically: Check whether extended view object metadata already exists for the target dimension information: If it exists, check whether the extended fields and nodes conflict with the source view object metadata; The conflicts include repetitiveness of field labels, numbers, names, and repetitiveness of node numbers and names.

[0009] According to an embodiment of the present application, the existence check of the business entity metadata is specifically: Check whether extended business entity metadata exists for the target dimension information, specifically including: The same business entity metadata is used for the same dimension in the card and the list; Check whether there are fields and nodes in the business entity that conflict with the source view object metadata.

[0010] According to an embodiment of the present application, the incremental copying and synchronization processing is performed according to the pre-check result, the source view object metadata, and the change increment to obtain the extended view object metadata and the mapping relationship, specifically: Extract the change increment between the source view object metadata and the upper-level view object of the source view object metadata; Process the newly added objects and fields, add them to the target view object, correct the parent object reference, and remove specific prefixes and suffixes; Update the mapping relationship of the newly added objects and fields to ensure that they point to the target business entity metadata; Synchronize the newly added objects and fields to the extended business entity.

[0011] According to an embodiment of the present application, it further includes: saving the extended view object metadata and other associated view object metadata.

[0012] According to an embodiment of the present application, after saving the metadata of the extended view object and the metadata of other associated view objects, it further includes: cleaning relevant caches in case of exceptions, where the relevant caches include caches of the metadata of the extended view object, the metadata of the business entity, and the metadata of other associated view objects.

[0013] A computer-readable storage medium, on which a program is stored, and when the program is executed by a processor, it implements the steps in the method.

[0014] An electronic device, including a memory, a processor, and a program stored on the memory and executable on the processor, and when the processor executes the program, it implements the steps in the method.

[0015] Due to the adoption of the above technical solutions, the beneficial effects obtained by the present application are as follows: By hierarchically analyzing the input dimension information, the present application accurately identifies the target dimension of the current operation and collects the metadata of the source view object accordingly. This provides a clear context basis for subsequent copy operations, ensures the pertinence and accuracy of the copy process, and avoids resource waste and logical confusion caused by blind copying.

[0016] By detecting conflicts in dimensions such as field tags, numbers, names, and node information between the existing metadata of the target dimension and the source metadata before copying, the present application effectively identifies and records potential conflict points. This mechanism significantly reduces the risk of system exceptions caused by reasons such as duplicate field names and duplicate nodes, and improves the security and stability of the copy operation.

[0017] Based on the change increment, the present application performs the copy operation, only processing the changed parts between the source VO and the superior VO, significantly improving the copy efficiency and reducing unnecessary data transmission and processing overhead. At the same time, the mapping relationship between the VO and the BE is automatically updated during the copy process to ensure that the newly generated extended VO can be correctly associated with the business entity, thus ensuring the consistency and integrity of the system logic. Description of the Drawings

[0018] The drawings described herein are used to provide a further understanding of the present application, and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation to the present application. In the drawings: Figure 1 It is a schematic flowchart of a multi-dimensional view object copying and synchronization method based on a low-code platform provided by an embodiment of the present application; Figure 2 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application.

[0019] Reference Signs: 810, Processor; 820, Communication Interface; 830, Memory; 840, Communication Bus. Detailed Implementation Manner

[0020] To more clearly illustrate the overall concept of this application, the following will be described in detail by way of examples in conjunction with the accompanying drawings of the specification.

[0021] In the following description, many specific details are set forth in order to provide a thorough understanding of this application. However, this application may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited by the specific embodiments disclosed below. It should be noted that, without conflict, the embodiments of this application and the features in each embodiment may be combined with each other.

[0022] In this application, unless otherwise clearly specified and limited, the first feature being "on" or "under" the second feature may be that the first and second features are in direct contact, or the first and second features are indirectly in contact through an intermediate medium. In the description of this specification, the description with reference to terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of this application. In this specification, the schematic descriptions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0023] Embodiment 1 As Figure 1 shown, an embodiment of the first aspect of this application provides a multi-dimensional view object copying and synchronizing method based on a low-code platform, including: Perform a dimension level judgment on the dimension information to confirm the target dimension information, and collect the source view object metadata based on the target dimension information.

[0024] As described above, first, the system receives an input (DimensionInfo) containing dimension information. This dimension information describes the specific level or classification targeted by the current operation. For example, in a low-code development platform, this may involve different parts of a form, such as different dimensions like cards, lists, etc.

[0025] Next, the system determines the specific dimension level of the current operation based on this dimension information. This means that the system needs to identify at which specific level the user wants to perform the copy operation. For example, does the user want to perform an operation within a specific card or within a certain list? Clearly defining this is crucial for the subsequent steps because it determines which data will be processed and how to process this data.

[0026] Once the dimension level is determined, the next step is to confirm the target dimension information. Here, "target dimension information" refers to the specific dimension determined based on the above dimension level judgment. For example, if it is determined that the operation is on a certain card, then the relevant information of this card (such as its identifier, name, etc.) will become part of the target dimension information.

[0027] The process of confirming the target dimension information also includes checking whether this dimension is suitable for performing the copy operation, that is, verifying whether this dimension exists and whether it meets the expected requirements. This is very important for ensuring the accuracy of the operation.

[0028] The last step is to collect the relevant source view object (SourceView Object, VO) metadata based on the confirmed target dimension information. Here, "collection" actually means collecting all the extended fields and node information related to this dimension. This information includes but is not limited to details such as the name, type, number, etc. of each field, as well as the relationship structure between them.

[0029] In this way, the system can obtain all the necessary source data, which will be used in subsequent steps to create new copies or perform other forms of operations, such as checking for conflicts, performing incremental copying, etc. This not only helps to maintain data consistency and integrity but also improves the efficiency of the entire process, enabling developers to more conveniently manage and adjust their customized content without worrying about data loss or chaos.

[0030] For example, suppose there is an enterprise resource management system (ERP) that includes a module for managing customer information. In this module, there is a form that allows users to input and edit basic customer information, such as name, contact information, etc. In addition, this form supports expansion according to different business requirements, such as adding new fields or cards to record more detailed customer preference information.

[0031] Now, the development team hopes to copy the existing "basic information" card to a new dimension without disturbing the existing functions, that is, create a new card dedicated to recording "customer preferences" and ensure that all related data (such as view object VO, business entity BE, etc.) can be correctly copied and associated.

[0032] First, the system receives a dimension information (DimensionInfo) indicating that the target of the current operation is the card dimension in the customer information form. Specifically, this dimension information may contain an identifier such as "basic information card".

[0033] Next, the system makes a dimension-level judgment based on this dimension information to confirm that the specific level of the current operation is at the level of the "basic information card". This means that the system recognizes that the user wishes to operate based on the existing "basic information" card.

[0034] Once the dimension level is determined to be the "basic information card", the next step is to confirm the target dimension information. In this case, the target dimension information refers to the relevant information of the new card to be created - namely, the "customer preference" card. The system needs to ensure that this new dimension (the "customer preference" card) is valid and can accept the data copied from the "basic information" card.

[0035] At this stage, the system also checks for any preset conditions or restrictions. For example, whether it is allowed to create multiple cards of the same type within the same form, or whether there are specific naming rules to follow, etc.

[0036] The last step is to collect the relevant source view object (VO) metadata based on the confirmed target dimension information (i.e., the "customer preference" card). This includes collecting all the extended fields and node information related to the "basic information" card. For example, if there are fields such as name, phone number, and email on the "basic information" card, then the information of these fields will be collected.

[0037] The content collected is not limited to the field names and types, but also includes their relationship structure, such as which fields belong to the same group and whether there are dependency relationships, etc. The purpose of doing this is to ensure that when this data is copied to the "customer preference" card, all the fields and their relationships can be maintained consistently, without data loss or relationship confusion.

[0038] Through the above steps, the development team can successfully copy the content of the "basic information" card to the new "customer preference" card, while ensuring data consistency and integrity, making the entire system more flexible and easy to maintain.

[0039] It should be noted that in a specific implementation scenario, based on the above solution, after collecting the source view object metadata, a data verification and cleaning step can be introduced. This step ensures that all the collected data is valid and conforms to the expected format and standards. For example, it can check whether the field names are unique, whether the data types are correct, and whether there are mandatory fields not filled in, etc. For data items that do not meet the requirements, the system can provide warnings or automatic correction functions.

[0040] In a specific implementation scenario, based on the above solution, when there is already some metadata in the target dimension, problems such as field or node conflicts may occur. In addition to simple conflict detection, an automated conflict resolution mechanism can also be developed. For example, automatically rename duplicate fields, merge similar fields, or prompt the user to manually select a solution according to predefined rules. This can reduce manual intervention and improve operation efficiency.

[0041] In a specific implementation scenario, based on the above solution, in order to better manage metadata changes of different versions, a metadata version control system can be introduced. Each time a copy operation is executed, the system will automatically generate a new version number and record all change details. This not only helps to track historical changes but also makes rollback possible. In addition, version control can also help team members collaborate better and avoid data loss problems caused by multiple people editing simultaneously.

[0042] Perform conflict checking on the target dimension information and the source view object metadata to obtain a pre-check result.

[0043] As described above, before copying the metadata of a source view object (VO) to a target dimension, the system needs to first confirm whether these data can exist in the target dimension without conflicts. This is to prevent newly added data from conflicting with existing data, such as duplicate field names, number conflicts, etc., thereby ensuring the stability of the system and the consistency of data.

[0044] The system first understands the specific situation of the current target dimension according to the target dimension information. This includes but is not limited to all extended VO metadata and business entity (BE) metadata already existing under this dimension.

[0045] Next, the system prepares the metadata of the source view object to be copied. These data include all extended field and node information. For example, all fields and their attributes (such as field labels, numbers, types, etc.) under a certain card dimension.

[0046] Field conflict detection: The system checks whether each field in the source view object already exists in the target dimension with the same or similar fields. Specifically, it compares key attributes such as field labels, numbers, and names to see if there are duplicates.

[0047] Node conflict detection: Similarly, similar checks will be performed on node information to see if there are the same node numbers or names.

[0048] Business Entity (BE) Conflict Detection: Since VOs are usually associated with BEs, the system also needs to check the BE metadata under the target dimension to ensure that the newly added VO fields do not conflict with the existing BE fields. This is particularly important when using the same BE in the same dimension.

[0049] Based on the results of the above detection, the system will generate a pre-check report. This report details all detected conflict points and corresponding recommended measures. For example, if a field name duplication is found, the report may recommend renaming the field; if there is a node number conflict, it may recommend adjusting the node number.

[0050] The pre-check results not only help developers understand potential problems but also provide a basis for subsequent manual adjustments or automatic corrections.

[0051] For example, assume that an online education platform is being developed, which includes a module for creating and managing courses. In this module, there is a form that allows administrators to enter basic course information (such as course name, description, etc.) and supports expanding course details according to different requirements, such as adding new fields to record the learning objectives or target audiences of the course.

[0052] Now, the development team wants to copy the existing "Basic Information" card to a new dimension - that is, create a new card specifically for recording "Learning Objectives" and ensure that all associated data (such as view objects VOs, business entities BEs, etc.) can be correctly copied and do not conflict with the existing data.

[0053] Target Dimension Information: The target dimension here refers to the upcoming "Learning Objectives" card. This card will store specific information about the learning objectives of the course.

[0054] Source View Object Metadata: These are the metadata from the "Basic Information" card, including but not limited to information about fields such as course name, course description, etc. Each field has its specific attributes, such as field label, number, type, etc.

[0055] Suppose there is a field named "Course Overview" with a field number of "001" in the "Basic Information" card. When attempting to copy this field to the "Learning Objectives" card, the system will check if there is already a field with the same name or number in the "Learning Objectives" card.

[0056] If it is found that there is already a field named "Course Overview" in the "Learning Objectives" card (even if its number is different), or a field with a number of "001" (even if its name is different), this constitutes a conflict.

[0057] Similarly, if some fields in the "Basic Information" card belong to a specific node (e.g., "Basic Information Node"), then during the copying process, the system will also check whether there is the same node number or name in the "Learning Objectives" card.

[0058] For example, if the number of the "Basic Information Node" is "N1" and there is already a node with the number "N1" in the "Learning Objectives" card, a conflict will occur.

[0059] In an online education platform, course information is usually closely related to the business entities (BEs) in the background. For example, information such as course names and descriptions may be directly associated with a certain BE.

[0060] When copying from the "Basic Information" card to the "Learning Objectives" card, the system needs to check whether there are any conflicts between the BEs associated with these two cards. For example, if the BE used in the "Learning Objectives" card already has similar fields (such as course overview) as those in the "Basic Information" card, there may be a conflict.

[0061] Based on the results of the above conflict detection, the system generates a pre-check report: If conflicts in field names or numbers are found, the report may suggest renaming these fields or adjusting their numbers to avoid conflicts.

[0062] For node conflicts, the report may suggest modifying the node numbers or names to make each node unique.

[0063] If there are conflicts at the BE level, the report may provide a detailed comparative analysis, indicating which fields may cause problems and proposing corresponding solutions, such as merging fields or adjusting field settings.

[0064] It should be noted that in specific implementation scenarios, on the basis of the above solutions, in addition to identifying conflicts, the system can provide automated or semi-automated solution suggestions. For example, when detecting a conflict in field names, the system can automatically generate new field names according to certain rules (such as adding a timestamp, number suffix, etc.) and prompt the user whether to accept these suggestions. This can reduce manual intervention and improve operation efficiency.

[0065] In specific implementation scenarios, on the basis of the above solutions, to help users better understand and handle conflicts, the system can assign a priority to each detected conflict. For example, conflicts in field names may be more urgent than conflicts in node numbers because they directly affect the display of the user interface. In this way, users can first resolve the most important conflicts and gradually optimize the entire system.

[0066] In a specific implementation scenario, based on the above solution, the system can record the results of each conflict check and analyze these historical data to identify common conflict patterns. Over time, the system can "learn" and predict the possible types of conflicts in the future, give preventive measures in advance or directly provide optimization suggestions during the design phase to avoid potential problems.

[0067] In a specific implementation scenario, based on the above solution, a user feedback mechanism can be introduced to allow users to submit their opinions or suggestions when viewing the conflict report. For example, if a certain solution provided by the system is not applicable, the user can directly mark it on the interface and explain the reason. These feedbacks can help improve future conflict detection algorithms and service quality.

[0068] Perform incremental replication and synchronization processing according to the pre-check results, the source view object metadata, and the change increments to obtain the extended view object metadata and the mapping relationship.

[0069] As described above, first, the system will carefully analyze all conflict points in the pre-check report. For example, duplicate field names, node number conflicts, etc.

[0070] Formulate solutions: According to the pre-check results, determine how to resolve these conflicts. For example, rename the conflicting fields or adjust the node numbers to avoid conflicts.

[0071] According to the pre-check results, select those fields and node information in the source view object that have no conflicts or have resolved conflicts.

[0072] If the source view object has changed since the last synchronization, it is necessary to prepare these change increments (such as newly added objects, fields, etc.) so that only the necessary updated parts are transmitted during replication instead of the entire data set.

[0073] Traverse the newly added objects in the change set (such as new form items). For each newly added object, add it to the view object under the target dimension and correct its parent object reference to ensure the correct hierarchy.

[0074] Similarly, process the newly added fields. Add them to the corresponding nodes and remove specific prefixes or suffixes (such as the "Ext_" prefix and the "_Lv9" suffix) as needed to make them conform to the standard format of the target dimension.

[0075] During the replication process, automatically maintain the mapping relationship between the VO and the BE. This means that for each newly added object or field, its corresponding BE mapping relationship needs to be updated to ensure consistency and interoperability between the two.

[0076] Not only ensure data synchronization from the VO to the BE, but also guarantee the effectiveness of reverse synchronization, that is, changes initiated from either the VO or the BE can be correctly reflected in the data model of the other party.

[0077] Synchronize the newly added objects and fields to the extended business entity (BE), ensuring that all relevant business logic and data integrity rules are applied.

[0078] The last step is to verify that all newly added content has been correctly added to the target dimension and that all mapping relationships have been established and are effective.

[0079] Through the above steps, the system can generate extended view object metadata and its mapping relationships with business entities. This includes not only all necessary fields and nodes copied from the source view object, but also all adjustments and optimizations made to adapt to the target dimension. This incremental copying method significantly improves efficiency because it only processes the parts that actually change, rather than the entire dataset, while maintaining the stability of the system and the consistency of the data.

[0080] For example, assume that a customer relationship management system (CRM) is being developed, which includes a module for recording customer information. In this module, there is a form that allows users to input and edit basic customer information, such as name, contact information, etc. In addition, this form supports extension according to different business requirements, such as adding new fields or cards to record more detailed customer preference information.

[0081] Now, the development team hopes to copy the existing "basic information" card to a new dimension - that is, create a new card specifically for recording "customer preferences" and ensure that all associated data (such as view object VO, business entity BE, etc.) can be correctly copied and associated.

[0082] Before performing the copy operation, the system conducts a conflict check and obtains the following pre-check results: Field name conflict: It is found that there is already a field named "Remarks" in the target dimension (i.e., the "customer preferences" card), and there is also a field with the same name in the source view object (the "basic information" card).

[0083] Node number conflict: There is a node with the number "N1" in the target dimension, and there is also a node with the same number in the source view object.

[0084] No BE conflict: Since the two cards use different business entities (BE), there is no conflict at the BE level.

[0085] The source view object (the "basic information" card) includes the following fields: Customer Name Contact Information Remarks (Name Conflict Exists) And Some Other Fields These fields all belong to a node with the node number "N1".

[0086] Assume that since the last synchronization, several fields have been added to the "Basic Information" card: Customer Source Referrer Information These newly added fields need to be considered in the incremental replication process.

[0087] Incremental Replication and Synchronization Processing Conflict Resolution: For the field name conflict (the "Remarks" field), the system recommends renaming the "Remarks" field in the source view object to "Other Remarks" to avoid conflicts.

[0088] For the node number conflict (node number "N1"), the system recommends adjusting the node number in the source view object to "N2".

[0089] The system selects the fields and node information to be replicated, including the modified field names and node numbers.

[0090] Prepare to add the newly added fields (Customer Source, Referrer Information) as part of the change increment.

[0091] Copy the fields in the "Basic Information" card (such as customer name, contact information, "Other Remarks", etc.) to the "Customer Preferences" card and adjust the corresponding node number to "N2".

[0092] The newly added fields (Customer Source, Referrer Information) are also added to the "Customer Preferences" card to ensure that they can be seamlessly integrated into the existing structure.

[0093] During the replication process, the system automatically updates the mapping relationship between each field and node and the corresponding business entity (BE). For example, ensure that the "Other Remarks" field is correctly mapped to the correct BE field.

[0094] Ensure that the data synchronization mechanism from VO to BE is effective so that any subsequent changes can be correctly reflected in the data models of each other.

[0095] All newly added objects and fields are synchronized to the extended business entity (BE) to ensure that all relevant business logics and data integrity rules are applied.

[0096] The last step is to verify that all newly added content has been correctly added to the target dimension and that all mapping relationships have been established and are effective.

[0097] It should be noted that in a specific implementation scenario, on the basis of the above solution, before performing incremental replication, an additional data verification and cleaning step can be introduced: The system automatically verifies whether all fields and node information to be replicated conform to the expected formats and standards. For example, it checks whether the field names are unique and whether the data types are correct. For data items that do not meet the requirements, the system can provide warnings or suggest corrective measures. For example, it automatically removes invalid characters or renames duplicate fields.

[0098] In a specific implementation scenario, on the basis of the above solution, in addition to manually resolving conflicts, an automated conflict resolution mechanism can also be developed: The system automatically adjusts the conflicting parts according to predefined rules. For example, for field name conflicts, a timestamp suffix (such as "Remarks_20250516") is automatically added to distinguish different versions. When the system detects a conflict, multiple solutions are provided for the user to choose from, and the user is allowed to customize the solution.

[0099] In a specific implementation scenario, on the basis of the above solution, in order to better manage changes to metadata, a version control system can be introduced: Each time an incremental replication operation is performed, the system creates a new version number and records all change details. This helps to track historical changes and also enables rollback. A detailed change log is generated, recording the content, time, and operator information of each change, which is convenient for auditing and problem troubleshooting.

[0100] According to an embodiment of the present application, the dimension information is judged at the dimension level to confirm the target dimension information, and the source view object metadata is collected based on the target dimension information, specifically: The current dimension level is judged according to the dimension information to obtain the target dimension information; The dimension information is information of a specific dimension level, and the target dimension information is the information of the target dimension to which the current replication is to be performed; The source view object metadata is all the extended fields and node information of the information of the target dimension to which the current replication is to be performed.

[0101] As mentioned above, dimension information refers to information about the specific level or classification targeted by the current operation. For example, in a low-code development platform, this may involve different parts of a form, such as different dimensions like cards and lists. Providing necessary context information enables the system to identify the specific level at which the user wishes to perform the replication operation.

[0102] Based on the input dimension information (DimensionInfo), the system first needs to determine which specific dimension level the current operation is targeted at. For example, is it intended to perform an operation within a specific card or within a certain list? Clarifying this is crucial for subsequent steps as it determines which data will be processed and how to process this data.

[0103] The target dimension information refers to the specific dimension determined based on the above dimension level judgment. For example, if it is determined that the operation is on a certain card, then the relevant information of this card (such as its identifier, name, etc.) will become part of the target dimension information.

[0104] The system will check whether this dimension is valid and meets the expected requirements. For example, ensure that this dimension actually exists and can accept data copied from other dimensions.

[0105] Prepare for the upcoming copy operation, including but not limited to clearing the cache, preparing storage space, etc.

[0106] The source view object metadata refers to all the extended field and node information to be copied to the target dimension. This information includes but is not limited to details such as the name, type, number of each field, and the relationship structure between them.

[0107] The system will traverse all the extended fields in the source view object, collect their attributes (such as name, type, number, etc.), and store this information in a structured manner (such as a HashMap structure of <node number, field list>).

[0108] In addition to the field information, node information will also be collected, that is, the larger structural units (such as groups, cards, etc.) to which these fields belong. Node information is usually stored in a list form for easy management and reference.

[0109] The system receives an input (DimensionInfo) containing specific dimension hierarchy information.

[0110] Based on the dimension information, the system determines the specific dimension level of the current operation. For example, it determines whether the operation is on the "Basic Information" card or the "Customer Preferences" card.

[0111] The system further confirms the validity of this dimension and prepares the corresponding environment for the copy operation.

[0112] According to the confirmed target dimension information, the system starts to collect all relevant extended field and node information. This includes the name, type, number of the fields and their belonging node information, etc.

[0113] According to an embodiment of the present application, the conflict check includes: view object metadata existence check and business entity metadata existence check.

[0114] As described above, the main purpose of the view object metadata existence check is to confirm whether there are the same or similar extended fields or node information in the target dimension as in the source view object. This step is to avoid generating duplicate data entries or field conflicts during the replication process.

[0115] The system checks each field name and number in the target dimension to see if there are fields with the same name or number as those in the source view object.

[0116] If duplicates are found, it may mean there are potential conflicts because two fields with the same name may cause data chaos or overwriting.

[0117] In addition to fields, node information is also checked. A node refers to a set of related fields, such as a card or group in a form.

[0118] The system checks whether there are the same node numbers or names in the target dimension as in the source view object to prevent node overlap or duplication.

[0119] Furthermore, the system also compares the specific attributes of the fields, such as data type, default value, etc., to ensure that these attributes are also unique or compatible in the target dimension.

[0120] The business entity metadata existence check aims to ensure that the business entities (BEs) used in the target dimension do not conflict with the BEs involved in the source view object. Business entities usually contain deeper data structures and logics, so this check is crucial for maintaining data consistency and integrity.

[0121] The system checks whether there are the same field names or numbers in the business entities in the target dimension as in the source view object.

[0122] If conflicts are found, such as two fields with the same name but different meanings, the system needs to decide how to handle this situation to avoid data confusion.

[0123] In addition to fields, the association relationships between BEs are also checked. For example, in a low-code development platform, a view object (VO) may be associated with multiple business entities (BEs), and there may be dependency relationships between these BEs.

[0124] The system needs to ensure that these dependency relationships can also be correctly established in the target dimension to avoid isolated or incomplete data structures.

[0125] Ensure that the business logic in the target dimension is consistent with the business logic in the source view object. For example, if a field has a specific validation rule or calculation logic in the source view object, the same rule and logic should be maintained in the target dimension.

[0126] According to an embodiment of the present application, the existence check of the view object metadata is specifically as follows: Check whether the extended view object metadata already exists in the target dimension information: If it exists, check whether there are conflicts between the extended fields and nodes and the source view object metadata; The conflicts include the repetition of field labels, numbers, and names, and the repetition of node numbers and names.

[0127] As described above, confirm whether the extended view object metadata already exists in the target dimension, and further check whether there are any conflicts between these existing metadata and the source view object metadata to be copied. Through this check, data chaos or overwriting problems caused by duplicate fields or nodes can be avoided.

[0128] The system first needs to determine whether the extended view object metadata already exists in the target dimension. Here, the "extended view object metadata" refers to all custom or extended fields and nodes that already exist in the target dimension.

[0129] If there is no existing extended view object metadata in the target dimension, the copy operation can be directly performed without worrying about conflicts. But if it exists, further checks are needed to prevent potential conflicts.

[0130] Once it is confirmed that the extended view object metadata already exists in the target dimension, the system will perform a more detailed conflict detection. This step mainly includes the following aspects: The system will compare each field label in the source view object with the existing field labels in the target dimension to see if there are the same labels. For example, if there is a field label "Remarks" in the source view object and there is also a field named "Remarks" in the target dimension, it is considered that there is a conflict.

[0131] In addition to the labels, the system will also check whether the field numbers are the same. Even if the field labels are different, the same number may cause conflicts because the number is usually a unique identifier.

[0132] Finally, the system will check whether the field names are repeated. For example, in some cases, the field names may be used in programming interfaces or database tables, so the uniqueness of the names is also important.

[0133] A node is a larger structural unit that contains a set of related fields, such as a card or a grouping. The system checks whether the node numbers in the source view object are duplicated with those in the target dimension. For example, if there is a node with the number "N1" in the source view object and there is also a node with the number "N1" in the target dimension, a conflict is considered to exist.

[0134] Similarly, the system also checks whether the node names are duplicated. Even if the numbers are different, the same name may cause confusion, especially when displayed in the user interface.

[0135] To better understand the content of the above checks, here are some specific conflict examples: The source view object has a field label of "Customer Name", and there is already a field with the same name in the target dimension. In this case, direct copying may cause field overwriting or data loss.

[0136] The source view object has a field number of "001", and there is also a field with the number "001" in the target dimension, even though their labels or names are different. This conflict may cause internal reference errors in the system.

[0137] The source view object has a node number of "N1", and there is also a node with the number "N1" in the target dimension. In this case, all fields under the node may be overwritten or confused.

[0138] The source view object has a node name of "Basic Information", and there is also a node with the same name in the target dimension. Even if the node numbers are different, the same name may cause confusion in the user interface.

[0139] Once a conflict is detected, the system can automatically process it according to preset rules or prompt the user to resolve it manually. For example: Automatically rename the conflicting fields or nodes, adding a timestamp or a suffix (such as "Remarks_20250516") to distinguish different versions.

[0140] Provide multiple solutions for the user to choose from and allow the user to customize the solution.

[0141] Through this meticulous conflict check, the system can ensure that each copy operation is safe and effective, thus maintaining the stability of the system and the consistency of the data.

[0142] According to an embodiment of the present application, the existence check of the business entity metadata is specifically: Check whether there is extended business entity metadata in the target dimension information, specifically including: The same business entity metadata is used for the same dimension of cards and lists; Check whether there are fields and nodes in the business entity that conflict with the source view object metadata.

[0143] As described above, confirm whether there is already extended business entity metadata in the target dimension, and further check whether there are any conflicts between these existing metadata and the source view object metadata to be copied. Through this check, data chaos or overwriting problems caused by duplicate fields or nodes can be avoided.

[0144] The system first needs to determine whether there is already extended business entity metadata in the target dimension. Here, "extended business entity metadata" refers to all custom or extended business logics and data structures that already exist in the target dimension.

[0145] If there is no existing extended business entity metadata in the target dimension, the copy operation can be directly performed without worrying about conflicts. But if there is, further checks are needed to prevent potential conflicts.

[0146] Once it is confirmed that there is extended business entity metadata in the target dimension, the system will perform more detailed conflict detection. This step mainly includes the following aspects: The same business entity metadata is used for the same dimension in cards and lists In a low-code development platform, different view objects (such as cards, lists) may share the same business entity (BE). For example, in a form, cards and lists may use the same business entity to store and manage data.

[0147] The system will check whether the cards and lists in the target dimension use the same business entity metadata.

[0148] If so, the system needs to pay special attention to ensuring that the newly added fields or nodes do not conflict with the existing business entity metadata.

[0149] The system will compare each field in the source view object with the fields in the business entity in the target dimension to see if there are the same field labels, numbers, or names.

[0150] For example, if there is a field with the label "Customer Name" in the source view object, and there is also a field named "Customer Name" in the business entity in the target dimension, it is considered a conflict.

[0151] Even if the field labels are different, the same number may also cause conflicts because the number is usually a unique identifier.

[0152] The uniqueness of field names is also important, especially when referenced in programming interfaces or database tables.

[0153] In addition to fields, the system also checks node information. A node refers to a larger structural unit that contains a set of related fields, such as a card or a group.

[0154] The system checks whether the node numbers in the source view object are duplicated with the node numbers in the business entities in the target dimension. For example, if there is a node with the number "N1" in the source view object and there is also a node with the number "N1" in the business entities in the target dimension, a conflict is considered to exist.

[0155] Similarly, the system also checks whether the node names are duplicated. Even if the numbers are different, the same name may cause confusion, especially when displayed in the user interface.

[0156] To better understand the content of the above checks, here are some specific conflict examples: There is a field label "Remarks" in the source view object, and there is also a field with the same name in the business entities in the target dimension. In this case, direct copying may cause field overwriting or data loss.

[0157] There is a field with the number "001" in the source view object, and there is also a field with the number "001" in the business entities in the target dimension, even though their labels or names are different. This conflict may cause internal reference errors in the system.

[0158] There is a node with the number "N1" in the source view object, and there is also a node with the number "N1" in the business entities in the target dimension. In this case, all fields under the node may be overwritten or confused.

[0159] There is a node with the name "Basic Information" in the source view object, and there is also a node with the same name in the business entities in the target dimension. Even if the node numbers are different, the same name may cause confusion in the user interface.

[0160] Once a conflict is detected, the system can automatically process it according to preset rules or prompt the user to resolve it manually. For example: Automatically rename the conflicting fields or nodes, adding a timestamp or a suffix (such as "Remarks_20250516") to distinguish different versions.

[0161] Provide multiple solutions for the user to choose from and allow the user to customize the solutions.

[0162] According to an embodiment of the present application, the incremental copying and synchronization processing is performed based on the pre-check result, the source view object metadata, and the change increment to obtain the extended view object metadata and the mapping relationship. Specifically: Use to extract the change increment between the source view object metadata and the upper-level view object of the source view object metadata; Process the newly added objects and fields, add them to the target view object, correct the parent object reference, and remove specific prefixes and suffixes; Update the mapping relationship of the newly added objects and fields to ensure that they point to the target business entity metadata; Synchronize the newly added objects and fields to the extended business entity.

[0163] As described above, use the change increment between the metadata of the extracted source view object and its parent view object to identify and extract the changes that have occurred in the metadata of the source view object since the last synchronization.

[0164] The system will compare the difference between the current metadata of the source view object and its parent view object (i.e., the previous version or the parent view object) to find the changed content such as newly added objects and fields.

[0165] These change increments usually include but are not limited to newly added objects (such as new form items), newly added fields, modified object attributes, etc.

[0166] Process the newly added objects and fields, add them to the target view object, correct the parent object reference, and remove specific prefixes and suffixes. Securely add the newly added objects and fields in the change increment to the target view object and ensure that these newly added contents meet the requirements of the target dimension.

[0167] Traverse the newly added objects (e.g., newly added form items) in the change increment, add them to the target view object, and correct the parent object reference. This step ensures that the newly added objects are correctly nested under their parent objects, maintaining the correct hierarchical structure.

[0168] If the newly added object has a parent object, its parent object reference needs to be updated to point to the correct parent object.

[0169] Similarly, process the newly added fields and add them to the corresponding nodes of the target view object.

[0170] Some fields may contain specific prefixes or suffixes (such as the "Ext_" prefix and the "_Lv9" suffix). These markers may be added to distinguish different versions or environments. During the copying process, the system will remove these markers to make the field names more concise and consistent.

[0171] Update the mapping relationship of the newly added objects and fields to ensure that they point to the target business entity metadata, maintain the mapping relationship between the view object (VO) and the business entity (BE), and ensure that the newly added objects and fields can be correctly associated with the corresponding parts in the target business entity.

[0172] For each newly added object and field, the system updates their mapping relationships to ensure that they point to the corresponding parts in the target business entity. For example, if a new field "customer source" is added, the system updates the mapping relationship of this field so that it points to the corresponding field in the target business entity.

[0173] Not only ensure data synchronization from VO to BE, but also guarantee the effectiveness of reverse synchronization, that is, changes initiated from either VO or BE can be correctly reflected in the data models of each other.

[0174] Synchronize newly added objects and fields to the extended business entity to ensure that all newly added objects and fields are not only processed at the view object level but also synchronized at the business logic level to maintain data consistency and integrity.

[0175] Synchronize the newly added objects and fields to the extended business entity (BE) to ensure that all relevant business logic and data integrity rules are applied.

[0176] The last step is to verify that all newly added content has been correctly added to the target dimension and that all mapping relationships have been established and are effective. This step ensures the stability of the system and data consistency.

[0177] According to an embodiment of the present application, it further includes: saving the extended view object metadata and other associated view object metadata.

[0178] As described above, ensure that all processed and adjusted extended view object metadata can be safely saved for subsequent use or further operations. By saving this data, the system can ensure that new or modified view objects can be correctly displayed in the user interface and that their underlying data structures can also support the corresponding business logic.

[0179] The system collects all newly added objects, fields, and their attribute information. This information includes but is not limited to field names, types, numbers, node information, etc.

[0180] Before saving, the system validates this metadata to ensure that it conforms to the expected format and standards. For example, check whether the field names are unique and whether the data types are correct.

[0181] Save the collected and verified extended view object metadata to the persistent storage of the system, such as a database or a specific file system. This step usually involves converting the metadata into a suitable storage format and performing the corresponding write operations.

[0182] In addition to saving the extended view object metadata, it is also necessary to save the metadata of other view objects associated with it. This is because in a complex system, view objects are often interrelated, and saving a single view object alone may lead to data inconsistency or unavailability in the entire system.

[0183] The system needs to identify which view objects are associated with the current extended view object. For example, in a form, multiple cards or lists may share the same business entity (BE), or some fields may be referenced across multiple view objects.

[0184] For each identified associated view object, the system will synchronously update their metadata. This means that if a field or node in the extended view object changes, the associated view objects also need to be adjusted accordingly.

[0185] Similar to the process of saving the extended view object metadata, the system will also verify and persistently store the metadata of the associated view objects to ensure that all associated data can be saved correctly without errors.

[0186] During the saving process, the system also needs to consider possible exceptional situations and take corresponding measures to maintain data consistency and integrity: If any error occurs during the saving process, the system should clear the relevant cached data to avoid data inconsistency problems caused by partially unsaved data.

[0187] Implement a transaction management mechanism so that in case of saving failure, it can roll back to the previous state to ensure that the system does not enter an unstable state.

[0188] According to an embodiment of the present application, after saving the extended view object metadata and the metadata of other associated view objects, it further includes: clearing the relevant cache in case of an exception, where the relevant cache includes the cache of the extended view object metadata, business entity metadata, and the metadata of other associated view objects.

[0189] As described above, when the system encounters an exception (such as network interruption, storage failure, or other errors) during the process of saving the extended view object metadata and the metadata of other associated view objects, it may cause some data to fail to be saved or updated successfully. If not properly cleared, these incomplete operations may lead to data inconsistency or an unstable system state. Therefore, the main purpose of clearing the relevant cache in case of an exception is: to ensure that the data state of the system matches the data actually stored. By clearing invalid or expired cached data, it helps the system resume normal operation.

[0190] The relevant caches that need to be cleared in case of an exception mainly include the following categories: The cache of extended view object metadata refers to the view object metadata that is newly added or modified in the current operation. For example, information such as newly added fields, nodes, etc. Caching this data can improve access efficiency, but in the event of an exception, if this data fails to be successfully saved to persistent storage, it needs to be removed from the cache to avoid problems during subsequent use.

[0191] The cache of business entity metadata refers to the business entity metadata associated with the view object. Business entities usually contain deeper data structures and logics, which are the supporting architectures behind view objects. When processing view object metadata, the business entity metadata is also affected. If the business entity metadata fails to be correctly updated in the event of an exception, then the relevant cache also needs to be cleared to prevent inconsistent data from affecting system functions.

[0192] The cache of other associated view object metadata refers to the metadata of other view objects that have dependencies or associations with the extended view object in the current operation. For example, different cards or lists that share the same business entity. Since there may be complex dependencies between view objects, a change in one view object may affect other view objects. If all relevant view object metadata fails to be synchronously updated in the event of an exception, then these cached data need to be cleared to ensure that the system does not make decisions based on outdated information.

[0193] The system first needs to have the ability to identify exceptions, that is, to detect abnormal situations when the save operation fails. This can be achieved by capturing exception events, checking the returned status codes, etc.

[0194] Once an exception is detected, the system needs to determine which caches are affected by this operation. This includes but is not limited to the caches of the extended view object metadata, business entity metadata, and other associated view object metadata mentioned above.

[0195] For the determined affected caches, the system will perform a cleanup operation, that is, remove these cached data from memory or mark them as invalid. This step ensures that these unsuccessfully saved data will not be used during the next access.

[0196] To facilitate subsequent analysis and debugging, the system usually also records the logs of the cleanup operation, including information such as the time of cleanup and the data scope involved.

[0197] In some cases, in addition to clearing the cache, the system may also take further recovery measures, such as attempting to re-execute the failed operation, prompting the user for manual intervention, or automatically rolling back to the previous state, etc.

[0198] A computer-readable storage medium, on which a program is stored, and when the program is executed by a processor, it implements the steps in the method.

[0199] An electronic device includes a memory, a processor, and a program stored on the memory and executable on the processor. When the processor executes the program, the steps in the method are implemented.

[0200] What is not described in this application can be implemented by adopting or referring to the prior art.

[0201] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other, and the key point of each embodiment is to illustrate the differences from other embodiments.

[0202] The above are only the embodiments of the present application and are not intended to limit the present application. For those skilled in the art, various changes and modifications can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the protection scope of the present application.

Claims

1. A multi-dimensional view object copying and synchronization method based on a low-code platform, characterized in that Including: Perform a dimension-level judgment on the dimension information to confirm the target dimension information, and collect the source view object metadata based on the target dimension information; Perform a conflict check on the target dimension information and the source view object metadata to obtain a pre-check result; Perform incremental replication and synchronization processing according to the pre-check result, the source view object metadata, and the change increment to obtain the extended view object metadata and the mapping relationship.

2. The method according to claim 1, characterized in that, The performing a dimension-level judgment on the dimension information to confirm the target dimension information and collecting the source view object metadata based on the target dimension information is specifically: Judge the current dimension level according to the dimension information to obtain the target dimension information; The dimension information is the information of a specific dimension level, and the target dimension information is the information of the target dimension to which it is currently to be copied; The source view object metadata is all the extended fields and node information of the information of the target dimension to which it is currently to be copied.

3. The method according to claim 1, wherein The conflict check includes: the existence check of the view object metadata and the existence check of the business entity metadata.

4. The method according to claim 3, characterized in that, The existence check of the view object metadata is specifically: Check whether the extended view object metadata already exists for the target dimension information: If it exists, check whether there are conflicts between the extended fields and nodes and the source view object metadata; The conflicts include the repeatability of field labels, numbers, and names, and the repeatability of node numbers and names.

5. The method according to claim 3, wherein The existence check of the business entity metadata is specifically: Check whether the extended business entity metadata exists for the target dimension information, specifically including: The same dimension of the card and the list uses the same business entity metadata; Check whether there are fields and nodes in the business entity that conflict with the source view object metadata.

6. The method according to claim 1, characterized in that, The performing incremental replication and synchronization processing according to the pre-check result, the source view object metadata, and the change increment to obtain the extended view object metadata and the mapping relationship is specifically: Extract the change increment between the source view object metadata and the upper-level view object of the source view object metadata; Process the newly added objects and fields, add them to the target view object, correct the parent object reference, and remove specific prefixes and suffixes; Update the mapping relationship of the newly added objects and fields to ensure that they point to the target business entity metadata; Synchronize the newly added objects and fields to the extended business entity.

7. The method according to claim 1, characterized in that It also includes: Save the extended view object metadata and the associated other view object metadata.

8. The method according to claim 7, wherein After saving the extended view object metadata and the associated other view object metadata, it also includes: clearing the relevant cache in case of an exception, where the relevant cache includes the cache of the extended view object metadata, the business entity metadata, and the associated other view object metadata.

9. A computer-readable storage medium having a program stored thereon, characterized in that, When the program is executed by a processor, it implements the steps in the method according to any one of claims 1-8.

10. An electronic device, comprising a memory, a processor, and a program stored on the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps in the method according to any one of claims 1-8.

Images