Method for merging record types in a data description language

Abstract

The application provides a merging method of record types in a data description language, which comprises the following steps: according to a recursive type definition, splitting a left original record type participating in the merging into a joint of a single attribute record and another record type, namely ({k:T}|R0); then recursively merging {k:T} and a right original record type, converting to obtain an intermediate type, and continuing to call the recursive merging processing with R0 to obtain a final result type. The result record type obtained through the merging method satisfies a well-formed condition, that is, all attribute names are unique, and the value types corresponding to the attribute names are well-formed. Through the merging algorithm of the application, the purpose of simplifying user operation and reducing operation and maintenance cost can be achieved, and the problem of record type conflicts possibly existing in multi-person collaborative development can be solved.

Description

Technical Field

[0001] This invention belongs to the field of data merging technology, and more specifically, relates to a record type merging algorithm based on a data description language of union types. Background Technology

[0002] The advent of the cloud-native era has driven the development of a new generation of software architectures. The functionality of many large-scale applications has been broken down into multiple independent requirement modules. These modules are implemented using a set of microservices and their combinations, with developers managing these microservices through complex configurations. In actual development, collaborative development by multiple teams has become the mainstream. Taking the configuration parameter `container:{port:(int|string)}` as an example, team A in a company might assign an integer value `m` to the `port` attribute, while team B might assign a string value `"m"`. This shows that both teams want to express the same semantics, but their programming habits differ. To make the complete application configuration effective, all configuration parameters need to be aggregated, and in this aggregation process, the handling of object data merging is crucial.

[0003] However, among the existing processing schemes available for merging object data, there are roughly two types: the traditional overwrite update principle based on right to left and the merging of objects that do not contain attributes with the same name.

[0004] The first approach, proposed by Cardelli et al., overwrites the original left objects sequentially from right to left. Its advantages are simplicity and ease of implementation, and it doesn't rely on complex calculations. However, its disadvantages include the potential loss of original data and its inability to resolve all record merging issues. Below is an example of runtime type overriding failure:

[0005] Suppose that the function f takes two record types x and y as input parameters and returns the result of merging x and y, then f = lambda x:{k:int}.lambda y:{h:bool}.(x||y)

[0006] Regarding the result type of f, {k:int}||{h:bool}={k:int,h:bool}, thus the result type is well-formed. If f accepts the following arguments:

[0007] x1={k=3,h=4}y1={k=true,h=false}

[0008] Then, applying function f to x1 and y1 using runtime type overriding will fail. Depending on the result type of f, the k property value of x1 should override the k property value of y1, and the h property value of y1 should override the h property value of x1. Therefore, one-way type overriding is insufficient to meet type requirements. One approach to solve this problem is to throw a runtime error, but this violates the principles of type checking; another approach is to compile specific instructions for (x1||y1), but this method is computationally expensive. Due to these difficulties, Harper and Pierce proposed a second solution: disallowing the merging of objects containing properties with the same name.

[0009] The second approach introduces a type assertion (#), i.e., R1#R2, indicating that the label sets of record types R1 and R2 are disjoint. In their merge transformation rule, the result type of the merge expression R1||R2 is well-formed only if R1 and R2 satisfy the predicate #. This approach avoids the failure of one-way type overriding encountered in the previous approach and also avoids the loss of original data. However, its drawbacks are that it requires an additional set of type assertion rules to constrain the merging algorithm, resulting in high formal verification costs; furthermore, this merging algorithm cannot solve the problem of {k:int}||{h:bool,k:float}. Summary of the Invention

[0010] The technical problem to be solved by the present invention is to address the above-mentioned defects in the prior art by providing a method for processing the result type of record type merging through union type, thereby avoiding data type conflicts that may occur in collaborative development by multiple teams.

[0011] To achieve the above technical objectives, this invention provides a record type merging algorithm based on union types for efficient collaboration among multiple teams, specifically including:

[0012] Step S1: Based on the information of each target node, determine the set of record types that need to be merged. The expression for merging any two record types is denoted as rec1||rec2. Then, iterate through each merging and transformation rule and match it according to the preconditions of the rule. For the matched rule, process it according to the calculation body of the rule to obtain the final result type.

[0013] For rules that do not match, proceed to step S2;

[0014] Step S2: Determine whether the record types rec1 and rec2 involved in the merging are empty;

[0015] If at least one is empty, the merged result is converted into another record type, and the calculated final configuration result is serialized into a YAML file, and the processing ends;

[0016] Otherwise, rec1 is recursively split into a single-attribute object and a union of another object, i.e. ({k:T}|R0), and proceed to step S3;

[0017] Step S3: Recursively split rec2 into a single-attribute object and a union of another object, i.e., ({h:Tp}|R2), and check whether {k:T} and {h:Tp} have the same attribute name;

[0018] If the same attribute name exists, proceed to step S32; otherwise, proceed to step S33.

[0019] Step S32: Check whether the value types corresponding to the same attribute name are consistent;

[0020] If the value types are consistent, then the type T corresponding to label k is taken as rec1, and the type Tp corresponding to label h is taken as rec2. Return to step S1 for further recursive merging. The final result type R1 is taken as the new type of the attribute with the same name k, that is, {k:R1} is denoted as A, and the processing ends.

[0021] If the value types are inconsistent, no merging process will be performed, and an error will be thrown.

[0022] Step S33, the corresponding merge expression for this case is {k:T}||({h:Tp}|R2), where the labels k and h are different;

[0023] If R2 is an empty record type {}, then return the union of {k:T} and {h:Tp}, that is, the final result type is {k:T,h:Tp}, and the processing ends;

[0024] Otherwise, if R2 is not empty, the single-attribute object participating in the merging is still {k:T}, and the split R2 is used as rec2. The process returns to step S31 for further recursive merging. The intermediate type R1 obtained by conversion is combined with {h:Tp} to calculate the final result type, which is denoted as A. The YAML configuration is output, and the process ends.

[0025] In step S4, the split R0 is used as rec1 and the intermediate type A is used as rec2. Then, return to step S2 for further recursive merging, calculate the final result type, and end the processing.

[0026] Beneficial Effects: The record type merging method based on union types provided in this application for efficient multi-team collaborative development can be applied to managing microservices and their combinations, thereby realizing independent requirement modules. First, resource configuration information from different teams is obtained to determine the data set for type merging. Then, according to the record type merging and conversion rules, the object types to be merged are merged to obtain the result type. Based on the calculated configuration result, a YAML configuration file is output, and the process ends. This avoids the possibility of type conflicts arising from different programming habits among teams when configuring record types individually, simplifies the user's resource configuration process, and achieves the goals of saving manpower and reducing operation and maintenance costs. Attached Figure Description

[0027] Figure 1 This is a schematic diagram illustrating the data merging steps according to an embodiment of this application;

[0028] Figure 2 This is a schematic diagram of one of the conversion rule bases for record type merging algorithms based on union types for efficient collaboration among multiple teams provided in this application;

[0029] Figure 3 This is a schematic diagram of the second part of the conversion rule base of the record type merging algorithm for efficient collaboration among multiple teams based on the union type provided in this application;

[0030] Figure 4 This is a diagram illustrating a common implementation scheme for collaborative development by multiple teams. Detailed Implementation

[0031] To enable those skilled in the art to more clearly understand the features and advantages of this application, the embodiments of this application are described in detail below with reference to the accompanying drawings. It should be noted that, under necessary constraints, the merging and conversion rules in this application can be combined with each other.

[0032] In this application, a static type rule system is used to obtain the final result type according to the record type merging and conversion rules based on the union type, thus avoiding conflicts in data operations. Subsequently, multiple teams configure the system under the constraints of the result type. This application can identify the value as the result type during compilation and perform type checks to locate and return any type errors.

[0033] Figure 1 A schematic diagram illustrating the data merging steps according to an embodiment of this application is shown. Figure 1 As shown, an embodiment of the record type merging method according to this application and the configuration based on the calculation result of record type merging is provided, mainly including the following steps:

[0034] Step S1: Based on the information of each target node, determine the set of record types that need to be merged. The expression for merging any two record types is denoted as rec1||rec2. Then, iterate through each merging and transformation rule and match it according to the preconditions of the rule. For the matched rule, process it according to the calculation body of the rule to obtain the final result type.

[0035] For rules that do not match, proceed to step S2;

[0036] Step S2: Determine whether the record types rec1 and rec2 involved in the merging are empty;

[0037] If at least one is empty, the merged result is another record type, and the calculated final configuration result is serialized into a YAML file, and the processing ends;

[0038] Otherwise, rec1 is recursively split into a single-attribute object and a union of another object, i.e. ({k:T}|R0), and proceed to step S3;

[0039] Step S3: Recursively split rec2 into a single-attribute object and a union of another object, i.e., ({h:Tp}|R2), and check whether {k:T} and {h:Tp} have the same attribute name;

[0040] If the same attribute name exists, proceed to step S31; otherwise, proceed to step S32.

[0041] Step S31: Check whether the value types corresponding to the same attribute name are consistent;

[0042] If the value types are consistent, then the type T corresponding to label k is taken as rec1, and the type Tp corresponding to label h is taken as rec2. Return to step S1 for further recursive merging. The final result type R1 is taken as the new type of the attribute with the same name k, that is, {k:R1} is denoted as A, and the processing ends.

[0043] If the value types are inconsistent, no merging process will be performed, and an error will be thrown.

[0044] Step S32, the corresponding merge expression for this case is {k:T}||({h:Tp}|R2), where the labels k and h are different.

[0045] If R2 is an empty record type {}, then return the union of {k:T} and {h:Tp}, that is, the final result type is {k:T,h:Tp}, and the processing ends;

[0046] Otherwise, if R2 is not empty, the single-attribute object participating in the merging is still {k:T}, and the split R2 is used as rec2. The process returns to step S3 for further recursive merging. The intermediate type R1 obtained by conversion is combined with {h:Tp} to calculate the final result type, which is denoted as A. The YAML configuration is output, and the processing ends.

[0047] In step S4, the split R0 is used as rec1 and the intermediate type A is used as rec2. Then, return to step S2 for further recursive merging, calculate the final result type, and end the processing.

[0048] The method described above in this application will be explained below in light of practical application needs:

[0049] like Figure 2 The image shows a schematic diagram of one of the conversion rule bases for record type merging algorithms based on union types. Here, we use the merging calls {k:{h:bool}} and {k:{l:int,h:int},m:float} as an example to illustrate:

[0050] The second record type {k:{l:int,h:int},m:float} can be split into a union of a single-attribute object and another object, resulting in ({k:{l:int,h:int}}|R), where the first record type {k:{h:bool}} and the split single-attribute object {k:{l:int,h:int}} have the same attribute name k;

[0051] Execute step S31. Value types corresponding to the same attribute name are all record types. Continue recursively merging {h:bool} and {l:int,h:int}. Starting from step S2, the recursion continues. The latter record type {l:int,h:int} can be split into ({l:int}|R). Since the former record {h:bool} and the split single-attribute object {l:int} do not have the same attribute name, execute step S33, that is, recursively merge the former record type {h:bool} and the other split object {h:int}. The intermediate type {h:(bool|int)} is combined with {l:int} according to the recursive type definition, resulting in the final type {h:(bool|int),l:int}. Return to the previous level and apply. Figure 2 Rule M in RS -3, resulting in {l:{h:(bool|int),l:int},m:float}, continue executing step S4, and end the processing.

[0052] To give another example, when merging record types {k:{h:bool}} and {k:int,m:string}, after executing step S3, the latter record type {k:int,m:string} can be split into ({k:int}|R);

[0053] According to step S31, check if there is a duplicate attribute name; if so, it exists.

[0054] Proceed to step S32, check if the value types corresponding to the same attribute name are consistent; if the attribute names are inconsistent, refuse to merge, throw an error, and prompt the user that the value types corresponding to the same attribute name are inconsistent and cannot be merged.

[0055] It should be noted that, Figure 2 The second merge conversion rule M in RS The -2 condition in RawUnionTp indicates that the table of this mixed type is not necessarily well-formed, and the member types may not be unique. However, after processing by the merging algorithm described in this invention, the resulting type will definitely be well-formed, that is, all attribute names are unique, and the value types corresponding to the attribute names are all well-formed. The conversion rule M... RS The -3 condition indicates that RawRecTp means that the record type is not necessarily well-formed. The attribute name may not be unique, or the value type corresponding to the attribute name may not be well-formed. However, after the merging process described in this invention, the resulting type will definitely be well-formed.

[0056] Combination Figure 2 traversal Figure 3 The merge conversion rules are as follows: (1) Check if the record types rec1 and rec2 to be merged are empty. If they are empty objects, the corresponding merge result is another object type; (2) If both rec1 and rec2 are not empty, then rec1 is split into a union of a single-attribute object and another record type according to the recursive type definition, i.e., ({k:T}|R0); (3) {k:T} and rec2 are recursively merged to obtain the intermediate type R1; (4) The other record type R0 obtained from the splitting is recursively merged with the intermediate type R1 to obtain the final result type R2. Thus, the final merge result is the call to the matching record type merge conversion strategy based on the union type.

[0057] For example, merging an empty object and a record type {k:{l:int},h:float}, the empty object is equivalent to rec1, and the latter record type is equivalent to rec2. Calling... Figure 3 The first conversion rule M in R If -1 is used, then the final merge result type will be the type of the next record.

[0058] For example, use {k:int,h:{l:bool}} and {k:float,h:{l:int}} as merge operands;

[0059] Execute step S2, split the previous record type {k:int,h:{l:bool}} into ({k:int}|R0), and recursively merge {k:int} and the next record type {k:float,h:{l:int}};

[0060] Execute step S3. At this point, the two record types involved in the merging are {k:int} and {k:float,h:{l:int}}. Split the right record type {k:float,h:{l:int}} to obtain ({k:float}|R2). Because there is a common label name, proceed to step S32. Since float is a subtype of int, int and float are merged, and the result is the parent type float. Use the resulting type as the new type of the attribute with the same name k, that is, convert to obtain the intermediate type {k:float}. Then, according to the recursive type definition and {h:{l:int}}, combine to obtain the final result type {k:float,h:{l:int}}, denoted as A; return to the previous level and apply. Figure 3 The third rule M R -3, continue merging {h:{l:bool}} and type A, apply. Figure 2 Rule M of the fourth RS -4. Continue merging {h:{l:bool}} and {h:{l:int}}, and proceed to step S32 to obtain the type {h:{l:(bool|int)}}, denoted as B. According to the recursive type definition, combine B and {k:float} to obtain {k:float,h:{l:(bool|int)}}, and the processing ends here.

[0061] like Figure 4 The diagram illustrates a common implementation scheme for collaborative development across multiple teams. In actual development, different teams have different programming habits. Client A sets the `port` attribute to an integer value `n`, and client B sets it to a string value `"n"`. Using the server's record type merging and conversion rules based on union types, the value of the `port` attribute is obtained as `container:{port:int|string}`. After processing, a YAML configuration file is output. If client C tries to change the `port` attribute to a boolean value `true`, an error will be thrown.

[0062] It should be noted that, in the embodiments of this application, the method Figure 2 , 3The resource configuration merging rules shown are illustrated using a specific example from the embodiments of this application. In actual implementation, the strategy configuration merging methods shown in the two method diagrams above can also be implemented using any other rules illustrated in the above embodiments, which will not be elaborated here.

Claims

1. A method for merging record types in a data description language, comprising the following steps: Step S1: Based on the information of each target node, determine the set of record types that need to be merged. The expression for merging any two record types is denoted as rec1||rec2. Then, iterate through each merging and transformation rule and match it according to the preconditions of the rule. For the matched rule, process it according to the calculation body of the rule to obtain the final result type. For rules that do not match, proceed to step S2; Step S2: Determine whether the record types rec1 and rec2 involved in the merging are empty; If at least one is empty, the merged result is converted into another record type, and the calculated final configuration result is serialized into a YAML file, and the processing ends; Otherwise, rec1 is recursively split into a single-attribute object and a union of another object, i.e. ({k:T}|R0), and proceed to step S3; Step S3: Recursively split rec2 into a single-attribute object and a union of another object, i.e., ({h:Tp}|R2), and check whether {k:T} and {h:Tp} have the same attribute name; If the same attribute name exists, proceed to step S32; otherwise, proceed to step S33. Step S32: Check whether the value types corresponding to the same attribute name are consistent; If the value types are consistent, then the type T corresponding to label k is taken as rec1, and the type Tp corresponding to label h is taken as rec2. Return to step S1 for further recursive merging. The final result type R1 is taken as the new type of the attribute with the same name k, that is, {k:R1} is denoted as A, and the processing ends. If the value types are inconsistent, no merging process will be performed, and an error will be thrown. Step S33, the corresponding merge expression for this case is {k:T}||({h:Tp}|R2), where the labels k and h are different; If R2 is an empty record type {}, then return the union of {k:T} and {h:Tp}, that is, the final result type is {k:T,h:Tp}, and end the processing; Otherwise, if R2 is not empty, the single-attribute object participating in the merging is still {k:T}, and the split R2 is used as rec2. The process returns to step S31 for further recursive merging. The intermediate type R1 obtained by conversion is combined with {h:Tp} to calculate the final result type, which is denoted as A. The YAML configuration is output, and the process ends. In step S4, the split R0 is used as rec1 and the intermediate type A is used as rec2. Then, return to step S2 for further recursive merging, calculate the final result type, and end the processing.

Images