A code generation verification method based on interface field list

Abstract

The application discloses an interface field list-based code generation checking method, relates to the technical fields of computer software development and code generation checking, and is used for solving the problem that in incremental update interfaces, the generated code retains the field appearance state, but the field appearance state is replaced by the field value state in the field processing or update execution process, leading to the problem that the update semantics such as non-update when not transmitting and empty clearing when transmitting are destroyed; the method acquires an interface field list and a generated code file set, determines an incremental update field, acquires state transmission information of the field appearance state in the generated code, judges whether the state is transmitted to an update execution position, and generates a code generation checking result of a state transmission exception when the state is not transmitted; thus, implicit update semantic errors in the generated code can be found in time, and the reliability of the interface code generation result is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a code generation and verification method based on an interface field list. Background Technology

[0002] With the development of API development, low-code development, and automated code generation technologies, developers typically maintain an API field list first. Then, code generation tools use this list to generate request objects, response objects, field mapping code, update objects, and corresponding API processing code. The API field list usually includes information such as field paths, field types, field descriptions, and field update semantics. For new APIs, query APIs, or ordinary full-scale modification APIs, existing code generation tools can usually generate field declarations, basic validation annotations, and object conversion code based on the field list, thereby reducing repetitive development work and improving the efficiency of API development.

[0003] However, in incremental update scenarios such as update interfaces, data modification interfaces, and configuration modification interfaces, whether a field appears in the current interface request usually has independent business meaning. For example, if a field does not appear in the request message, it usually means that the original field value will not be modified; if the field appears in the request message and its value is empty, it may mean that the original field value will be cleared; if the field appears in the request message and its value is a specific value, it means that the original field value will be overwritten with this specific value. Therefore, incremental update fields need to express not only the field value itself, but also the state of whether the field appears in the current interface request. In existing code generation methods, although the field appearance state can be expressed at the request object layer through field wrapping structures, field appearance flags, request field sets, or field binding records, the subsequently generated field processing code, object mapping code, or update execution code may not necessarily continue to retain this field appearance state.

[0004] For example, the API field list might specify that the user nickname field is an incremental update field. If the field doesn't appear, it means the nickname won't be modified; if the field appears and its value is an empty string, it means the nickname should be cleared. However, after the code generation tool retains the field's presence status in the request object, it might determine whether to write the field based solely on whether the field value is empty during the mapping or update execution code. In this case, the field's presence status is replaced by its value status during the intermediate processing of the generated code, causing the explicit intention to clear the field to fail to be passed to the update execution location. Existing code generation verification typically focuses on whether fields have been generated, whether field types are consistent, or whether field validation rules exist. It's difficult to detect the problem of field presence status being lost in the code generation chain. This could lead to unpassed fields being updated incorrectly, the intention to clear fields being missed, or the incremental update semantics being broken. Summary of the Invention

[0005] This application provides a code generation verification method based on an interface field list to identify situations where the appearance status of incrementally updated fields in the generated code is not propagated to the update execution location, thereby reducing the risk of confusion between the appearance status of fields that are not present and the appearance status of fields in the generated code; the technical solution is as follows: On the one hand, a code generation and verification method based on an interface field list is provided, the method including: To obtain the list of interface fields, and the collection of code files generated based on this list of interface fields; Based on the interface field list, determine the incremental update fields. The incremental update fields mentioned here are those fields that need to be distinguished between the fields that have not appeared and the fields that have appeared. From the code file set, obtain the status transmission information corresponding to the incremental update field. This status transmission information is used to characterize the field occurrence status of the incremental update field and its transmission in the generated code. Based on the status transmission information, determine whether the field occurrence status of the incremental update field has been transmitted to the corresponding update execution position; In response to the fact that the status of the field has not been passed to the update execution location, it is determined that there is a status transmission anomaly in the incremental update field; Based on this status transmission exception, generate code to produce the verification result.

[0006] In one possible implementation, the process of determining the incremental update field based on the interface field list includes: obtaining the field path and field update semantic information from the interface field list; when the field update semantic information indicates that no update is performed when the field does not appear, and an update is only allowed when the field has appeared, the field corresponding to this field path is determined as the incremental update field.

[0007] In one possible implementation, the process of obtaining the status transmission information corresponding to the incremental update field from the code file set includes: determining the request object code, field processing code, and update execution code corresponding to the incremental update field from the code file set based on the field path of the incremental update field; and obtaining the status transmission information based on the request object code, the field processing code, and the update execution code.

[0008] In one possible implementation, the process of obtaining status transmission information based on request object code, field processing code, and update execution code includes: obtaining field occurrence status information from request object code; obtaining field status processing information from field processing code; obtaining update execution control information from update execution code; and generating the status transmission information based on the field occurrence status information, the field status processing information, and the update execution control information.

[0009] In one possible implementation, the field occurrence status information includes at least one of the following: a field wrapping structure, a field occurrence flag, a request field set, a field binding record, or a status judgment expression.

[0010] In one possible implementation, the update execution control information includes at least one of conditional branches, conditional parameters, update call statements, field assignment statements, or update wrapper statements.

[0011] In one possible implementation, the process of determining whether the occurrence status of an incremental update field has been passed to the corresponding update execution position based on the status transmission information includes: determining whether the update execution control information directly uses the field occurrence status information, or whether it uses intermediate status information obtained from the field occurrence status information; if the update execution control information neither directly uses the field occurrence status information nor uses the intermediate status information, then it is determined that the field occurrence status has not been passed to the update execution position.

[0012] In one possible implementation, in response to the field occurrence state being replaced by the field value state during field processing, it is determined that there is a state transmission anomaly in the incremental update field; wherein, the field value state includes at least one of the following: whether the field value is empty, whether the field value is an empty string, whether the field value is an empty set, whether the field value is equal to a preset default value, or whether the field value is equal to a preset unset placeholder value.

[0013] In one possible implementation, the code generation verification result includes at least one of the following: the field path of the incremental update field, the exception type of the state transmission exception, the code location corresponding to the state transmission exception, or the verification description corresponding to the state transmission exception.

[0014] In one possible implementation, the method further includes: generating a verification result based on the code, and generating a status transmission correction prompt message; wherein, this status transmission correction prompt message is used to prompt the generated code corresponding to the incremental update field to retain the field occurrence state, or to prompt the update control basis at the update execution position to be adjusted to the field occurrence state.

[0015] The solution provided in this application embodiment is not merely to verify whether the fields in the interface field list exist in the generated code, nor is it merely to verify whether the field types or field validation rules are consistent. Rather, it is specifically designed for incremental update fields to obtain the state transmission information of the field's occurrence status in the generated code and to determine whether the field's occurrence status has been transmitted to the corresponding update execution position. In this way, it can identify situations where the field's occurrence status is clearly present in the request object code, but this field's occurrence status is lost during the field processing or update execution process. This reduces the risk that update semantics such as "no update if field does not appear" or "update is only allowed if field has appeared" are broken in the generated code. Attached Figure Description

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

[0017] Figure 1 This is a flowchart of a code generation and verification method based on an interface field list provided in an embodiment of this application; Figure 2 This is a schematic diagram illustrating the generation of status transmission information provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating the identification of an anomaly in state transmission provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the implementation methods of this application will be described in more detail below with reference to the accompanying drawings.

[0019] It is understood that the terms "first," "second," etc., used in this application may be used to describe various concepts, but unless otherwise specified, these concepts are not limited by these terms. These terms are merely for distinguishing one concept from another.

[0020] In this application embodiment, "field occurrence status" refers to whether a field is carried in the current interface request; "field occurrence status information" refers to the field structure, variable, expression, or record in the generated code used to represent the field occurrence status; "status transmission information" refers to the information used to characterize the field occurrence status, starting from the request object code, passing through the field processing code, and finally to the update execution code; "update execution position" refers to the code position in the generated code that can cause the corresponding field to be written, overwritten, cleared, or remain unchanged; "status transmission exception" refers to an exception where the field occurrence status is not used as the control basis for the update execution position, or is replaced by the field value status during the field processing process.

[0021] Figure 1 This is a flowchart illustrating a code generation and verification method based on an interface field list, as provided in this application embodiment. This application embodiment can be executed by a computer device or by a code generation and verification tool deployed on a computer device. See also... Figure 1 This method includes: S101, The computer device obtains the list of interface fields and the set of code files generated based on this list of interface fields; The interface field list can be a table file, an interface documentation file, an interface description file, or a field configuration file exported by the interface management platform. The interface field list includes field paths, and may also include field types, field descriptions, field update semantic information, interface operation types, or the interface identifier to which the field belongs. The field path is used to identify the position of the field in the interface request object. For example, the field path may include the field name, the path of a nested object, or the path of an array element, etc. This application embodiment does not limit this.

[0022] The code file set is a collection of code files generated based on the interface field list. The code file set may include at least one of the following: request object code, field processing code, object mapping code, update execution code, entity object code, or database update code. The request object code is used to carry the fields in the interface request. The field processing code is used to read, convert, unpack, or pass the status of the request object fields. The update execution code is used to perform field update writes. The code generation verification tool in this embodiment takes the interface field list and the code file set as input and outputs the code generation verification results.

[0023] Optionally, the code file set may include code files generated by Java, TypeScript, Go, Python, or other programming languages; the code generation verification tool may identify the request object code, field processing code, and update execution code through at least one of the following methods: abstract syntax tree parsing, syntax markup parsing, symbol reference analysis, configuration mapping relationship, or text matching; the embodiments of this application do not limit the specific programming language, as long as it can identify the request object field, field processing process, and update execution location corresponding to the field path.

[0024] S102. The computer equipment determines the incremental update fields based on the interface field list; Among them, incremental update fields are those fields that need to be distinguished between the state of "field not appearing" and the state of "field appearing". The state of "field not appearing" means that the current interface request does not carry this field; the state of "field appearing" means that the current interface request carries this field. The field value can be null, empty string, empty set, default value or specific business value.

[0025] Optionally, the computer device obtains the field path and field update semantic information from the interface field list. When the field update semantic information indicates that no update will be performed if the field does not appear, but an update is allowed only if the field has appeared, the computer device identifies the field corresponding to this field path as an incremental update field. For example, in the user profile modification interface, the field with the field path user.nickName is marked as an incremental update field. If the field does not appear, it means that the nickname will not be modified. If the field has appeared and the field value is empty, it means that the nickname will be cleared. If the field has appeared and the field value is a specific string, it means that the nickname will be overwritten.

[0026] It should be noted that the field update semantic information can be determined by the update semantic column, interface scenario column, field remark column, field attribute identifier, or interface operation type in the interface field list; as long as a certain field can be determined, and it is necessary to decide whether to perform an update based on whether the field appears in the interface request, this field can be identified as an incremental update field. This application embodiment does not limit the specific recording form of the field update semantic information.

[0027] S103. The computer device retrieves the status transmission information corresponding to the incremental update field from the code file set; Optionally, the code generation verification tool can construct a state transmission information record for each incremental update field. This state transmission information record may include a field path field, a source node field, a processing node field, a target node field, a control dependency field, a data dependency field, a field value state substitution type field, and a code location field. Here, the field path field records the field path of the incremental update field in the interface field list; the source node field records the code node in the generated code that carries the field's state; the processing node field records the code node that reads, unpacks, assigns, maps, or transforms the incremental update field; and the target node field is used... The code nodes for executing updates and writes are recorded; the control dependency field is used to record whether the target node is controlled by the field occurrence status judgment; the data dependency field is used to record whether the field occurrence status has been passed to the target node through variables, parameters, object fields, or collection elements; the field value status substitution type field is used to record whether the field occurrence status has been replaced by field value states such as field value empty, field value empty string, field value empty collection, field value equal to default value, or field value equal to no placeholder value, etc.; the code location field is used to record the file name, class name, method name, line number, or statement identifier of the source node, processing node, and target node in the code file collection.

[0028] For example, the state transmission information record can include sourceNode, processNode, sinkNode, controlDependency, dataDependency, valueStateSubstitutionType, and codeLocation. Here, sourceNode represents the source node of the field's state, processNode represents the field processing node, sinkNode represents the update execution node, controlDependency indicates whether the sinkNode is controlled by the sourceNode or an intermediate state obtained from the sourceNode, dataDependency indicates whether the field's state reached the sinkNode through the data stream, valueStateSubstitutionType indicates which field value state replaced the field's state, and codeLocation indicates the code location corresponding to the exception. The field names mentioned above are only used to describe the composition of the state transmission information, and this application embodiment does not limit the specific field names.

[0029] Code generation verification tools can use the field path of incremental update fields as an index to associate the field status information in the request object code, the field status processing information in the field processing code, and the update execution control information in the update execution code with the same status transmission information record. If the same code snippet includes both field processing and update execution processes, the code generation verification tool can identify the field reading, unpacking, conversion, object construction, or intermediate variable assignment content in this code snippet as processNode, and identify the field assignment, update call, update parameter binding, database write, or update wrapper write content as sinkNode.

[0030] Status propagation information is used to characterize the status of an incrementally updated field and how it is propagated in the generated code. This status propagation information can indicate whether the field status exists in the request object code, whether the field status has been propagated by the field processing code, and whether the field status has reached the update execution position in the update execution code.

[0031] To avoid limiting the embodiments of this application to a specific code syntax, the state transfer verification process under different generation methods will be described below in the form of code generation method logic.

[0032] In one possible implementation, the code generation verification tool can follow the logic of "generating field appearance status, generating field values, passing status and field values ​​separately, and binding update execution positions" to verify the code generated based on the interface field list. Specifically, when generating code corresponding to incremental update fields, the code generation tool can generate a field appearance status carrying structure and a field value carrying structure for this field. The field appearance status carrying structure is used to indicate whether the field appears in the current interface request, and the field value carrying structure is used to indicate the specific value of the field in the current interface request. During verification, the code generation verification tool will identify the code node corresponding to the field appearance status carrying structure as sourceNode, the code node corresponding to field reading, unpacking, assignment, mapping, construction update parameters or builder parameter passing as processNode, and the field writing position in field assignment, update wrapper writing, database update, mapper update or SQL update statement as sinkNode.

[0033] For generation methods using nullable wrapper structures or field wrapper structures, the code generation method should use the "whether the field appears" judgment result as the control basis for update execution, and use the field value extraction result as the write value. For example, the judgment result that indicates that the field has appeared in the interface request, such as isPresent, isDefined, or isSet, can be used as the status judgment corresponding to the sourceNode, and the result obtained by orElse, getValue, or similar value retrieval methods can be used as the field value. If the generated code first unpacks the wrapper field into a normal field value in processNode, and only uses whether this normal field value is empty to control whether to write in sinkNode, then the code generation verification tool will determine that the field appearance status has not been passed to the update execution position, and the field appearance status has been replaced by the field value status.

[0034] When using methods that generate request field sets or key-value sets, the code generation method should treat the existence of the target field name in the set as the field's presence status, and the value corresponding to the target field name in the set as the field value. For example, it can use containsKey, hasOwnProperty, or key existence checks as field presence status checks, and treat the get or property read results as field values. If the generated code only controls the update based on whether the field value obtained by get is empty, without controlling the update based on whether the set contains the target field name, then in the case where the field exists but the field value is empty, the update execution may be blocked, and the code generation verification tool will determine that the field presence status is abnormally propagated. The correct generation logic is as follows: the existence of the key controls whether the sinkNode should be executed, and the value corresponding to the key is used as the write value of the sinkNode.

[0035] When using Optional or similar optional wrapper objects for generation, code generation verification tools need to determine whether the wrapper object can express the field's presence status. If Optional is only used to indicate whether a field value exists and cannot distinguish between the two states of a field not appearing in the request and a field appearing but with an empty value, then Optional itself should not be treated as field presence status information alone. In this case, the code generation method can generate a field presence flag, a request field set record, or a field binding record outside the field value wrapper object, and use this field presence flag, request field set record, or field binding record to control whether the update execution position should be written. Optional or similar objects are only used to carry field values ​​or the nullable state of field values.

[0036] For generation methods that use update wrappers to perform field writes, the code generation verification tool can identify the update wrapper write call as a sinkNode and the condition parameters in this write call as update execution control information. For example, in a set call with condition parameters, the condition parameters should be bound to the field occurrence status judgment result, and the write value parameter should be bound to the field value extraction result. If the condition parameters are bound to whether the field value is empty, whether the field value is an empty string, whether the field value is an empty set, or whether the field value is equal to the default value, it means that the sinkNode is controlled by the field value status, but not by the field occurrence status. When the interface field list specifies that a field has occurred and its value is empty, but a clear write still needs to be performed, the code generation verification tool will determine that this update wrapper write call has a field value status substitution situation.

[0037] For cross-file and cross-method generation methods, code generation verification tools can establish a state propagation chain along field paths, variable names, method parameters, object properties, field mapping configurations, or database column names. Fields in the request object code that carry state can serve as sourceNodes; method parameters, return object fields, constructor parameters, builder parameters, update command object fields, or intermediate state variables in the mapping method can serve as processNodes; and repository layer save calls, mapper update calls, set clauses in SQL update statements, update wrapper write calls, or entity field assignment statements can serve as sinkNodes. If field state propagation is passed to the sinkNode via parameter passing, object field assignment, update parameter binding, request field set passing, or an outer unified update strategy, then the field state propagation has been reached at the update execution location. If the processNode only passes field values, and the sinkNode only controls the update based on whether the field value is empty, an empty string, an empty set, or a default value, then the field state propagation has not been reached at the update execution location.

[0038] In multi-language generation scenarios, the specific syntax of the code generation method may differ, but the verification logic will remain consistent. For TypeScript code, the existence check of an object property can be treated as the field presence status, and the property value as the field value. For Go code, the field presence flag or map key existence check can be treated as the field presence status, and the field pointer or field value as the field value. For Python code, the existence of the target key in the dictionary can be treated as the field presence status, and the dictionary value can be treated as the field value. The field access methods differ across languages, but all can build state transmission information around sourceNode, processNode, and sinkNode, and determine whether the field presence status is replaced by the field value status in the generated code chain.

[0039] Optionally, the code generation verification tool can also perform false positive elimination processing. If the field value status judgment is only used for field validity verification, rather than to control whether the sinkNode should perform the write operation, then it is uncertain whether it is a status propagation exception. If the sinkNode does not directly reference the field status judgment, but is controlled by the outer unified update strategy, and this unified update strategy can control the update write by requesting the field set, the field occurrence flag table, or the field binding record, then it is also uncertain whether it is a status propagation exception. If the field status is propagated to the update execution location through configuration files, annotations, interceptors, serialization binders, or the framework runtime mechanism, and the code generation verification tool can confirm this propagation relationship, then it is also uncertain whether it is a status propagation exception.

[0040] Using the above methods, the code generation verification tool can identify the source node, field processing node, and update execution node of the field appearance status in the generated code based on the field path and field update semantic information in the interface field list, without relying on specific code syntax. It can also determine whether the update execution node uses the field appearance status as the basis for update control, thereby discovering anomalies in the generated code chain where the field appearance status is replaced by the field value status.

[0041] Based on the above code generation method logic, the following section will explain the process for judging state propagation exceptions when the field's state is not propagated to the update execution location.

[0042] Optionally, the computer device determines the request object code, field processing code, and update execution code corresponding to the incrementally updated field from the code file set based on the field path of the incrementally updated field. The request object code can be a request class, request structure, request parameter object, or interface parameter object. The field processing code can be a mapping method, conversion method, field unpacking statement, object copy statement, or update parameter construction statement. The update execution code can be an entity field assignment statement, update wrapper statement, database update call statement, or service layer update method call statement.

[0043] Optionally, the computer device retrieves field presence status information from the request object code. This field presence status information indicates whether the incrementally updated field appears in the interface request. The field presence status information may include at least one of the following: a field wrapping structure, a field presence flag, a request field set, a field binding record, or a status judgment expression. For example, when the request object code uses an optional wrapping structure to carry a field, the presence status of this optional wrapping structure can serve as the field presence status information. When the request object code uses a boolean field presence flag, this flag can serve as the field presence status information. When the request object code records the original request field set, whether this set contains the corresponding field name can serve as the field presence status information.

[0044] Optionally, the computer device obtains field status processing information from the field processing code; the field status processing information is used to indicate how the field occurrence status is processed in the field processing process; the field status processing information may include information such as whether the field occurrence status has been read, whether it has been assigned to an intermediate variable, whether it has been passed to an update parameter object, whether it has been unpacked into a field value, or whether it has been replaced with a field value status.

[0045] Optionally, the computer device obtains update execution control information from the update execution code; the update execution control information is used to indicate whether the incremental update field is to be written; the update execution control information may include at least one of conditional branches, conditional parameters, update call statements, field assignment statements, or update wrapper statements; for example, if the update execution code contains an if condition to control whether the field is written, this if condition can serve as update execution control information; if the update execution code contains an update wrapper statement with conditional parameters, these conditional parameters can serve as update execution control information.

[0046] Optionally, when generating status transmission information, the code generation verification tool uses the field path of the incremental update field as an index to associate the field status information in the request object code, the field status processing information in the field processing code, and the update execution control information in the update execution code. If the same code segment includes both field processing and update execution processes, then the field reading, unpacking, conversion, or intermediate variable assignment content in this code segment is identified as field status processing information, and the field assignment, update call, update parameter setting, or database write content in this code segment is identified as update execution control information.

[0047] Optionally, the status transmission information may include field path, request object code location, field occurrence status information, field processing code location, field status processing information, update execution code location, update execution control information, and the association result between field occurrence status and update execution control information; the computer device may store the status transmission information in the form of a table, graph, list, or key-value structure, and this application embodiment does not limit this.

[0048] Optionally, the code generation verification tool can locate the update execution position corresponding to the incremental update field from the code file set based on the update execution identification rules; these update execution identification rules may include at least one of the following: method name identification rules, annotation identification rules, call chain identification rules, SQL statement identification rules, ORM update wrapper identification rules, repository interface identification rules, or mapping file identification rules.

[0049] In one possible implementation, when the code file set includes object-oriented language code, the code generation verification tool can identify field assignment statements, setter call statements, builder assignment statements, update command object construction statements, repository save calls, service update calls, or mapper update calls as candidate update execution locations. In another possible implementation, when the code file set includes SQL statements or mapping files, the code generation verification tool can identify set clauses in SQL update statements, update tags in mapper XML, field binding expressions in dynamic SQL, and set calls or setSql calls in ORM update wrappers as candidate update execution locations.

[0050] Optionally, the code generation verification tool can match candidate update execution positions with incremental update fields based on at least one of the field path, field name, database column name, object attribute name, interface field alias, or field mapping configuration of the incremental update field. When the candidate update execution position can cause the data corresponding to the incremental update field to be written, overwritten, cleared, or remain unchanged, the code generation verification tool determines the candidate update execution position as the update execution position corresponding to the incremental update field.

[0051] S104. The computer device uses status transmission information to determine whether the status of the incremental update field has been transmitted to the corresponding update execution location; See Figure 2The interface field list and code file set serve as inputs to the code generation and verification tool. The interface field list can include field paths and field update semantic information, while the code file set can include request object code, field processing code, and update execution code. Based on the field paths in the interface field list, the code generation and verification tool retrieves field occurrence status information from the request object code, field status processing information from the field processing code, and update execution control information from the update execution code.

[0052] The code generation verification tool generates status propagation information based on field occurrence status information, field status processing information, and update execution control information. Then, it uses this information to determine if the field occurrence status has been propagated to the update execution location. If the field occurrence status has been propagated, a code generation verification result indicating that the verification has passed is generated. If the field occurrence status has not been propagated, a status propagation anomaly is identified, and a corresponding code generation verification result is generated. Optionally, the tool can also generate status propagation correction prompts based on the verification results.

[0053] The update execution location is the position in the generated code where the incremental update field is written. This update execution location can be the field assignment location, the update call location, the database update parameter setting location, or the update wrapper writing location. As long as this location can cause the data corresponding to the incremental update field to be written, overwritten, cleared, or remain unchanged, it can be regarded as the update execution location.

[0054] Optionally, the computer device determines whether the update execution control information directly uses the field occurrence status information or whether it uses intermediate status information obtained by passing the field occurrence status information. This intermediate status information can be a variable obtained by assigning a value to the field occurrence status information, an update parameter constructed by the field occurrence status information, or a processing result obtained after the field occurrence status information is passed to the field processing method.

[0055] Optionally, when the update execution control information directly references the field occurrence status information, or references an intermediate variable obtained by assigning a value from the field occurrence status information, or calls an update parameter object constructed from the field occurrence status information, or when the conditional branch where the update execution location is located is controlled by the field occurrence status judgment expression, the code generation verification tool will determine whether the field occurrence status has been passed to the update execution location; if the update execution control information merely references the field value itself, the result of a non-empty field value, the result of a non-empty string field value, the result of a non-empty set of field values, the result of a comparison of the field's default value, or the result of a comparison of a field without a placeholder value, then the code generation verification tool will determine whether the field occurrence status has not been passed to the update execution location.

[0056] Optionally, when the field status does not appear in the update execution code as an explicit variable, explicit conditional branch, or explicit method parameter, the code generation verification tool can also determine whether the field status has been indirectly passed to the update execution location through the framework mechanism based on the complex framework confirmation rules. The complex framework confirmation rules mentioned can include at least one of the following: configuration file confirmation rules, annotation confirmation rules, serialization binding confirmation rules, interceptor confirmation rules, ORM runtime confirmation rules, or unified update strategy confirmation rules.

[0057] In one possible implementation, if the code file set contains field binding configurations, and these field binding configurations explicitly record the set of fields that have appeared in the request message, and the update method called at the update execution location uses this set of fields as the basis for update filtering, then the code generation verification tool can determine that the field appearance status is passed to the update execution location based on the configuration file.

[0058] In another possible implementation, if there are annotations on the request object fields, update command object fields, or update method parameters, and these annotations are used to instruct the runtime to only perform updates on fields that have already appeared in the interface request, then the code generation verification tool can confirm, based on the annotation declaration, annotation processor configuration, or framework binding rules, that the field's state is passed to the update execution location via the annotation mechanism.

[0059] In another possible implementation, if the serializer binder or request parser generates a field binding record, a field presence flag table, or a request field set when parsing the request message, and the update execution code uses this field binding record, field presence flag table, or request field set to control field writing, then the code generation verification tool can determine that the field presence status is passed to the update execution location by the serializer binder.

[0060] In another possible implementation, if the interceptor, aspect component, ORM runtime mechanism, or unified update strategy reads the field occurrence record before the update is executed, and uses this field occurrence record to filter the fields actually written, then even if a single update execution node does not directly reference the field occurrence status judgment, the code generation verification tool can determine that the field occurrence status has been indirectly passed to the update execution location.

[0061] If the code generation verification tool cannot confirm the control or data relationship between the field's state and the update execution location using configuration files, annotations, serialization binders, interceptors, ORM runtime mechanisms, or unified update strategies, then the field will be marked as pending verification. When the field also has a situation where the field value state is replaced, a code generation verification result of the pending verification type can be generated to prompt developers to conduct further verification.

[0062] For example, the request object code records whether the nickName field appears in the request. However, the field processing code first unpacks the nickName field into a regular string, and then in the update execution code, it controls whether to update this field by checking if the string is empty. In this case, the update execution control information does not use the appearance status of the nickName field, but uses the field value status as the basis for update control. The computer device then determines the appearance status of the nickName field, which is not passed to the update execution location.

[0063] Optionally, the code generation verification tool can determine whether the field's state has been passed to the update execution location based on at least one of the following: abstract syntax tree, symbolic reference relationship, control dependency relationship, data dependency relationship, method call parameter passing relationship, or update wrapper parameter binding relationship.

[0064] When the conditional branch of the update execution location directly references the field occurrence status information, or when the conditional parameters of the update execution location are generated from the field occurrence status information, the code generation verification tool determines that the field occurrence status is passed to the update execution location through control dependencies. When the field occurrence status information is assigned to an intermediate variable, and this intermediate variable is referenced by the update execution location, the code generation verification tool determines that the field occurrence status is passed to the update execution location through data dependencies. When the field occurrence status information is passed as a method call parameter to the field processing method, and the return result or output parameter of the field processing method continues to control the update execution location, the code generation verification tool determines that the field occurrence status is passed to the update execution location through method call parameters. When the field occurrence status information is bound to an update wrapper, update command object, update parameter object, or field update set, and the object or set participates in the control judgment of the update execution location, the code generation verification tool determines that the field occurrence status is passed to the update execution location through update parameter binding.

[0065] If the update execution location only references the field value itself, the result of the field value not being null, the result of the field value not being null string, the result of the field value not being null set, the result of the field value default value comparison, or the result of the field value not having a placeholder value comparison, but does not reference the field occurrence status information, the intermediate status information generated from the field occurrence status information, or the update parameter object that retains the field occurrence status, then the code generation verification tool will determine that the field occurrence status has not been passed to the update execution location.

[0066] In this application embodiment, intermediate state information refers to state information that is directly or indirectly generated from field occurrence state information and can continue to indicate whether the field appears in the interface request. This intermediate state information may include at least one of the following: field occurrence flag variable, boolean variable obtained by assigning a value to the field occurrence state, DTO mapping field that retains the field occurrence state, constructor parameter, builder parameter, Optional wrapper object, JsonNullable wrapper object, Map collection containing field names, request field collection, field binding record, reflection binding metadata, or update parameter object.

[0067] Optionally, the code generation verification tool can identify the association between intermediate state information and the original field occurrence state information based on symbolic reference relationships, assignment relationships, parameter passing relationships, object field mapping relationships, or collection inclusion relationships. When this intermediate state information can distinguish between the field not occurring state and the field already occurring state, it is determined that this intermediate state information retains the field occurrence state. When this intermediate state information only retains the field value itself, or only retains the judgment result of the field value being empty, the field value being not empty, the field value being an empty string, the field value being an empty collection, or the field value being a default value, it is determined that this intermediate state information does not retain the field occurrence state.

[0068] Optionally, when the code generation verification tool determines an anomaly in state transmission, it focuses on the control basis of the update execution position as the key judgment object. The control basis of the update execution position refers to the conditions, parameters, filtering rules, or outer control strategies that determine whether the target node executes field writing, field overwriting, field clearing, or field update parameter binding. When the execution of the target node is controlled by the field occurrence status judgment, the control basis of the target node can be determined as the field occurrence status. The field occurrence status judgment can include at least one of the following: the occurrence judgment of the field packaging structure, the field occurrence flag, the request field set inclusion judgment, the field binding record, the field occurrence status intermediate variable, or the update parameter object that retains the field occurrence status.

[0069] When the execution of a target node is controlled by whether a field value is empty, whether a field value is an empty string, whether a field value is an empty collection, whether a field value is equal to a default value, whether a field value is equal to an unset placeholder value, or whether a field value wrapper object is empty, the control basis for the target node can be determined as the field value status.

[0070] If the interface field list indicates that the target field is an incremental update field, and the control basis of the target node is the field value status rather than the field occurrence status, then the code generation verification tool will determine that there is an error in the control basis of the update execution location. In this case, even if the request object code already has a field occurrence status carrying structure, as long as this field occurrence status does not become the control basis for whether the target node should execute the update, it will be determined that the field occurrence status has not been passed to the update execution location.

[0071] For example, for an incremental update field with the path user.nickName, if the request object has already generated the field's presence status, but the update execution location controls whether to write based on whether nickName is empty, whether nickName is an empty string, or whether nickName is equal to the default value, then the control basis of the target node is the field value status. If the field list specifies that a clear write should be performed when the field has appeared and the field value is empty, then this control basis will prevent the clear intention from reaching the update execution location, and the code generation verification tool will determine that there is a status propagation exception.

[0072] Using the above judgment method, this application embodiment will focus the verification on whether the field occurrence status of the incremental update field becomes the control basis for the update execution position; when the field occurrence status is replaced by the field value status, and the update execution position decides whether to write based on the field value status, it is determined that there is an abnormality in the code generation link.

[0073] In one possible implementation, the code generation verification tool can construct a cross-file state transmission chain for incrementally updated fields based on the request object code, field processing code, and update execution code in the code file set. This state transmission chain can include sourceNode, processNode, and sinkNode. Here, sourceNode represents the source node where the field's state appears; processNode represents the processing node in the field processing process where the field's state or value appears; and sinkNode represents the update execution location. The code generation verification tool can associate sourceNode, processNode, and sinkNode with the same incrementally updated field's state transmission information based on field path, variable name, method parameter, object property, field mapping configuration, or database column name.

[0074] For example, in the interface field list, the field with the path `user.nickName` is defined as an incremental update field. If the field doesn't appear, it means no update; if the field appears and its value is empty, it means clearing; if the field appears and its value is a specific string, it means overwriting. If the request object code uses a `JsonNullable` wrapper structure to hold the `nickName` field, then this `JsonNullable` field, or its corresponding `isPresent` condition, can serve as the `sourceNode`. If the field processing code reads the `nickName` field and passes it to the update command object, then the corresponding read statement, assignment statement, constructor parameter, or builder parameter can serve as the `processNode`. If the update execution code calls the update wrapper's `set` method, the entity object's `setter` method, the mapper's update method, or the `set` clause in an SQL update statement, then the corresponding update call node can serve as the `sinkNode`.

[0075] In one possible implementation, for incremental update fields that use field wrapper structures to carry the field's status, the code generation verification tool can identify the wrapper field or status judgment expression in the request object that indicates whether the field appears in the interface request as the sourceNode; identify the statement that performs read, unwrap, or assign operations on the field as the processNode; and identify the statement that performs field write, update wrapper write, database update, or entity assignment as the sinkNode.

[0076] For example, for an incremental update field with the path user.nickName, the interface field list can be defined as follows: if the field does not appear, the nickname is not modified; if the field appears and its value is empty, the nickname is cleared; if the field appears and its value is a specific string, the nickname is overwritten. If the generated code records the appearance status of the nickName field in the request object using a nullable wrapper structure or a field appearance flag, but in the field processing code, nickName is first unpacked into a normal field value, and then in the update execution code, the decision to write is based solely on whether this normal field value is empty, then the code generation verification tool will determine that the field appearance status between sourceNode and sinkNode is not effectively transmitted, and the field appearance status is replaced by the field value status. In this case, when the interface request explicitly passes an empty value or an empty string, the update execution position may not execute the clear and write operation, thus determining that there is an anomaly in the state transmission of this incremental update field.

[0077] In the correct generation method, the code generation tool should pass the field occurrence status and field value to the update execution location respectively. That is, whether the update execution location should perform an update should be controlled by the field occurrence status; the content to be updated should be provided by the field value. For wrapper fields, the update writing can be controlled by the judgment result indicating that the field has occurred; for request field sets, the update writing can be controlled by whether the set contains the field name; for field occurrence flags, the update writing can be controlled by this flag. In this way, an update will not be triggered when the field does not occur, a clear write can still be performed when the field has occurred and the field value is empty, and an overwrite write can be performed when the field has occurred and the field value is a specific value.

[0078] In another possible implementation, for the generated code that uses a key-value set to carry the request field, the code generation verification tool can identify the sourceNode as the judgment of whether the request field set contains the target field name, the processNode as the statement that reads the target field value from the request field set, and the sinkNode as the statement that executes the update write based on this field value. If the generated code only controls the update based on whether the field value retrieved from the set is empty, without controlling the update based on whether the set contains the target field name, then the update execution may be blocked when the field has appeared but the field value is empty, and the code generation verification tool will determine that there is a state transit exception. The correct generation method is as follows: take whether the request field set contains the target field name as the basis for update execution, and take the corresponding field value in the set as the write value.

[0079] In another possible implementation, for code generated using Optional or similar optional wrapper objects, the code generation verification tool needs to determine whether the wrapper object can distinguish between the field's absence and the field's presence. If the wrapper object only indicates whether the field value exists and cannot distinguish between the two situations—the field not appearing in the request and the field appearing but with an empty value—then the wrapper object should not be identified as the field's presence information. In this case, the correct code generation method can generate a field presence flag, a request field set record, or a field binding record in addition to the field value wrapper object, and use this field presence flag, request field set record, or field binding record to control whether the update execution location should be written.

[0080] In another possible implementation, for the generated code that uses an update wrapper to execute field writes, the code generation verification tool can identify the update wrapper write call as a sinkNode and identify the condition parameter in this call as update execution control information. If this condition parameter depends on whether the field value is empty, whether the field value is an empty string, whether the field value is an empty set, or whether the field value is equal to the default value, it means that the update execution position is controlled by the field value state. If the interface field list specifies that the field is an incremental update field, and a clear write still needs to be executed when the field has appeared but the field value is empty, then the code generation verification tool will determine that this update wrapper write call has a state propagation anomaly where the field appearance state is replaced by the field value state. The corresponding correct generation method is as follows: set the condition parameter of the update wrapper write call to the field appearance state judgment result, and set the write value parameter to the field value extraction result, so that the control basis for update execution and the write data are independent of each other.

[0081] In cross-file and cross-method scenarios, code generation and verification tools can trace the transmission of field appearance states along the method call chain. The field appearance state carrying structure in the request object code can serve as the sourceNode; method parameters, return object fields, constructor parameters, builder parameters, or update command object fields in the mapping method can serve as the processNode; and repository layer save calls, mapper update calls, set clauses in SQL update statements, or update wrapper write calls can serve as the sinkNode. If the field appearance state is passed to the sinkNode via parameter passing, object field assignment, update parameter binding, or request field set, then the field appearance state has been transmitted to the update execution location. If the processNode only passes the field value, and the sinkNode only controls whether to update based on the field value state, then the field appearance state has not been transmitted to the update execution location.

[0082] S105. In response to the situation where the status of a field has not been passed to the update execution location, the computer device determines whether there is a status passing exception for the incremental update field; Optionally, in response to a field occurrence state being replaced by a field value state during field processing, the computer device determines that there is a state transmission anomaly in the incremental update field; wherein, the field value state may include at least one of the following: whether the field value is empty, whether the field value is an empty string, whether the field value is an empty set, whether the field value is equal to a preset default value, or whether the field value is equal to a preset unset placeholder value; the preset unset placeholder value is used to indicate a placeholder value that the field has not been set, such as a preset string, a preset numerical value, or a preset enumerated value, which is not limited in this embodiment.

[0083] For example, the interface field list specifies that the nickName field is an incremental update field. When the field has already appeared and its value is an empty string, it means that the nickname should be cleared. However, in the generated code, the update execution code only writes to the field when the nickName field value is not an empty string. In this case, the field's existence status is replaced by the field's value not being an empty string status. As a result, when the field has already appeared but its value is an empty string, the update cannot be executed, and the computer device will determine that there is a state propagation exception for this field.

[0084] For example, the interface field list specifies that the `goodsList` field is an incrementally updated field. If the field does not appear, the original list is not updated; if the field appears and its value is an empty set, the original list is cleared. However, the generated code initializes the `goodsList` field that does not appear as an empty set, and in the subsequent update execution code, it determines whether to update based on whether the set is empty. In this case, the states of the field not appearing and the fields of the field appearing and its value being an empty set may be merged, and the computer device can determine that there is a state propagation anomaly for this field.

[0085] See Figure 3 In the API field list, the field with the path user.nickName is defined as an incremental update field. For this field, if it doesn't appear, it means no update; if it appears and is an empty string, it means clearing; if it appears and has a specific value, it means overwriting. The request object code can retain the appearance status of the nickName field to indicate whether this field appears in the current API request.

[0086] In the field processing code, if the code generation tool only reads or unpacks the field value of the nickName field without continuing to pass the field presence status of the nickName field, then this field presence status may be replaced by the field value status during the field processing process. Furthermore, in the update execution code, if the generated code controls whether to perform the update based on whether "nickName is a non-empty string", then when an empty string is explicitly passed in the interface request, the update execution code will prevent the writing of this field, thus causing the intention to clear the nickname to be unable to be passed to the update execution location.

[0087] Therefore, code generation verification tools can be based on Figure 3 The displayed state propagation chain determines that although a field in the request object's code has a state, this state is not propagated to the update execution location in the update execution code, and based on this, it is determined that the user.nickName field has a state propagation anomaly.

[0088] For example, the interface field list specifies that the age field is an incremental update field. If the field does not appear, the age will not be modified. If the field appears and its value is 0, it means that the age should be updated to 0. If the generated code initializes the age field, which does not appear, to 0 by default, and determines whether to perform the update based on whether age is equal to 0 in the update execution code, then the field's existing state will be replaced by the field's default value state. The computer device can then determine that there is a state propagation exception for this field.

[0089] Optionally, before determining the state transmission exception, the code generation verification tool will first perform a false judgment exclusion confirmation; the false judgment exclusion confirmation is used to determine whether the field value state judgment has indeed replaced the field's state, or whether it is merely an auxiliary judgment that does not affect the update control basis.

[0090] In one possible implementation, if the field value status check is only used to perform validity checks on the field value, and does not control whether the target node should perform the write operation, then it is not identified as a status transmission exception. For example, if the target node is already controlled by the field occurrence status check, and the length, format, enumeration range, or numerical range of the field value is checked within the branch where the field has occurred to see if they meet the requirements, then the field value status check is a validity check, not a field occurrence status replacement.

[0091] In another possible implementation, if the field value status check is located after the field occurrence status check, and the field occurrence status check has already controlled whether the target node should be executed, then it is not considered a status propagation exception. For example, the generated code first uses the field occurrence flag to determine whether to enter the update branch, and then checks whether the field value meets the business validity requirements within this update branch. In this case, it can be determined that the field occurrence status has been propagated to the update execution position.

[0092] In another possible implementation, if the target node does not directly reference the field occurrence status judgment, but is controlled by the outer unified update strategy, and this unified update strategy controls the field writing by relying on the request field set, the field occurrence flag table, the field binding record, or the changedFields set, then it is also not determined as a status transmission exception; in this case, the request field set, the field occurrence flag table, the field binding record, or the changedFields set can serve as intermediate state information that retains the field occurrence status.

[0093] In another possible implementation, if the field status is passed to the update execution location through configuration files, annotations, interceptors, serializers, ORM runtime mechanisms, or framework runtime binding rules, and the code generation verification tool can confirm this passing relationship based on configuration mappings, annotation declarations, field binding metadata, or framework rules, then it is not considered a status passing exception.

[0094] If the target field belongs to a creation interface field, query interface field, full update field, response field, read-only field, or server-generated field, then the code generation verification tool will not perform incremental update field state transmission exception judgment for this field. For full update fields, the field does not have the semantics of maintaining the original value if the state does not appear. Therefore, the state transmission exception verification in this application embodiment is not suitable for use here.

[0095] If the code generation verification tool cannot confirm that the field value status judgment is only used for legality verification, nor can it confirm that the target node is controlled by the outer unified update strategy or the framework runtime mechanism, and the execution condition of the target node depends on the field value status rather than the field occurrence status, then it can be determined that this field does not meet the conditions for excluding false positives.

[0096] Optionally, before determining the state transmission exception, the code generation verification tool can also perform false positive elimination processing. If the interface field list indicates that the target field belongs to a full update field, a create interface field, a query interface field, a response field, or a read-only field, then the code generation verification tool will not determine this field as an incremental update field, or will not perform state transmission exception judgment on this field.

[0097] Optionally, if the update execution location does not directly reference the field's status information, but the generated code contains an outer unified update strategy, and this unified update strategy can control the writing of all incremental update fields based on the requested field set, field appearance flag table, or field binding record, then the code generation verification tool can determine that the field does not have a status propagation exception. If the field's status does not appear explicitly in the current code file, but is uniformly propagated to the update execution location by configuration files, annotations, interceptors, serialization binders, or framework runtime mechanisms, and the code generation verification tool can confirm this propagation relationship based on configuration mapping relationships or framework binding rules, then it will not be identified as a status propagation exception.

[0098] Optionally, if the field value status check is only used for field value validity verification and not for controlling whether the update execution position should be written, then the code generation verification tool will not determine this field value status check as a field occurrence status replacement; if the field value not null check is located after the field occurrence status check, and the field occurrence status check has already controlled whether the update execution position should be executed, then the code generation verification tool will not determine this field value not null check as a status transmission exception.

[0099] Optionally, the code generation verification tool can perform misjudgment elimination work before determining state transmission anomalies. If the field value state judgment is only used to verify the validity of the field value, and not to control whether the sinkNode should perform the update, then it will not be determined as a state transmission anomaly. For example, if the generated code first uses the field appearance state judgment to control whether the update execution position should be executed, and then checks whether the length of the field value meets the requirements within the branch where the field has already appeared, then this field value length judgment is only a validity check and does not belong to the field appearance state substitution.

[0100] Optionally, if the generated code uses an outer unified update strategy to control the writing of all incrementally updated fields, and this unified update strategy can determine whether a field has appeared in the interface request based on the request field set, the field appearance flag table, or the field binding record, then even if a single sinkNode does not directly reference the field appearance status judgment, the code generation verification tool will not identify it as a status transmission exception. For example, if the generated code writes all the fields that have appeared into a unified changedFields collection, and a unified update method performs field updates based on this changedFields collection, then this changedFields collection can act as intermediate state information.

[0101] Optionally, if the code framework uses annotations, serializers, interceptors, ORM framework runtime mechanisms, or configuration files to pass the field's state to the update execution location, the code generation verification tool can confirm this passing relationship based on the configuration file, annotation declaration, field binding metadata, or framework binding rules. If it can be confirmed that the field's state is still used as the basis for update execution at runtime, then it will not be identified as a state passing exception.

[0102] Optionally, if the target field belongs to a creation interface field, query interface field, full update field, response field, read-only field, or field generated by the server, then the code generation verification tool can skip performing state transmission exception judgment on this field. For full update fields, the field has no state and does not have the semantics of maintaining the original value, so the incremental update field state transmission verification described in this application embodiment is not applicable.

[0103] S106. The computer equipment generates code to generate verification results based on the status transmission anomaly; The code generation verification result may include at least one of the following: the field path of the incremental update field, the exception type of the status transmission exception, the code location corresponding to the status transmission exception, or the verification description corresponding to the status transmission exception; the code location may include the request object code location, the field processing code location, the update execution code location, or the location of the update execution control information.

[0104] Optionally, the exception types in the code generation verification results may include: field status not reaching the update execution position, field status being replaced by field value not empty, field status being replaced by field value not empty string, field status being replaced by field value not empty set, field status being replaced by field default value, field status being replaced by field not set placeholder value, etc.; the specific names of exception types are not limited in this application embodiment.

[0105] Optionally, the computer device can also generate a status transmission correction prompt based on the code generation verification result; this status transmission correction prompt is used to prompt that the field's occurrence status be retained in the generated code corresponding to the incremental update field, or to prompt that the update control basis at the update execution position be adjusted to the field's occurrence status.

[0106] Optionally, the status transmission correction message may include the field path, the location of the exception code, the current update control basis, the suggested field appearance status information, and the suggested adjustment location. For example, if the code generation verification tool determines that the update execution location of the field user.nickName uses nickName != null as the update condition, but the interface field list indicates that user.nickName is an incremental update field, the code generation verification tool can generate a correction message suggesting that the update condition be adjusted to the result of judging whether user.nickName appears in the interface request.

[0107] It should be noted that the embodiments of this application are not general improvements to the code generation driven by the interface field list, nor are they general distinctions between the absence of fields and the null value of fields in the partial update interface; the verification object of the embodiments of this application is whether the control basis of the incremental update field in the code generation chain has been replaced.

[0108] Specifically, the core focus of this application's embodiments is: the interface field list has already indicated that the target field is an incremental update field, and the request object code may also contain a field appearance status carrying structure, but in the field processing code, mapping code, or update execution code, does the update execution position still use the field appearance status as the basis for whether to execute the write? If the update execution position is changed to control whether to write based on the field value status such as whether the field value is empty, whether the field value is an empty string, whether the field value is an empty set, or whether the field value is equal to the default value, then it can be determined that the field appearance status is replaced by the field value status.

[0109] Therefore, the state transmission anomaly identified in this application embodiment is a hidden anomaly within the code generation chain. This anomaly does not necessarily manifest as missing fields, incorrect field types, or missing field validation rules. Rather, it manifests as the field's state not reaching the update execution position, or in other words, although the field's state exists in the request object, it ultimately does not become the control basis for the update execution position. By identifying this anomaly, we can discover incremental update semantic violations that are difficult to detect in a timely manner by ordinary code generation verification and ordinary parameter validation.

[0110] This application provides a code generation verification method based on an interface field list. It goes beyond simply determining whether field declarations exist in the generated code or whether field types or validation rules are consistent. Instead, it specifically targets incrementally updated fields, acquiring their occurrence status and verifying the status transmission information across the request object code, field processing code, and update execution code. It also determines whether the field occurrence status has been passed to the update execution location. This allows for the identification of situations where the field occurrence status is replaced by the field value status during field processing, thereby reducing the risk of update semantics such as not updating if the field does not appear or only updating if the field has appeared being violated in the generated code.

[0111] It should be noted that the embodiments described above are merely possible implementations of this application; those skilled in the art can adjust the field path matching method, code snippet recognition method, and verification result display method according to the specific programming language, code generation framework, or interface field list format. As long as the incremental update field is still determined based on the interface field list, and the status of the field is determined to be passed to the update execution position, they all fall within the implementation scope of the embodiments of this application.

[0112] It should be noted that the embodiments of this application do not limit the specific programming language of the code file set; for programming languages ​​such as Java, TypeScript, Go, Python or other programming languages, the code generation verification tool can identify the request object code, field processing code and update execution code based on field paths, field names, object attribute names, method call relationships, assignment relationships or update call relationships; for code files for which a complete abstract syntax tree cannot be obtained, the code generation verification tool can use at least one of the following methods to determine the state transmission information: syntax markup parsing, text pattern matching, symbol table parsing, configuration file mapping, or manually configured field mapping rules.

[0113] The multi-language adaptation in this application's embodiments does not change the core verification logic of this application. Under different programming languages ​​or code generation frameworks, the basis for judgment is whether the field appearance state of the incrementally updated field has been passed to the update execution position in the code generation chain; when the field appearance state is replaced by the field value state in the request object code, field processing code, or update execution code, an anomaly in state transmission is determined.

[0114] In multi-language implementations, the core logic of the code generation method remains consistent. For TypeScript code, the check for whether an object possesses the target field property can be used as the field's presence status, and the property value can be treated as the field value. If the generated code excludes both undefined and null cases for the target property, the update execution might be prevented when the field already exists and its value is null (indicating clearing). Correspondingly, the correct generation method can use the object property existence check as the basis for update execution, and treat the object property value as the write value.

[0115] For Go code, field presence flags or map structures can be used to record field presence status. If the generated code only determines whether to update based on whether the field pointer is nil, it may not be able to distinguish between cases where a field has not appeared and cases where a field has appeared and needs to be cleared under certain request binding methods. Accordingly, the correct generation method can generate field presence flags during the request parsing phase and use these flags at the update execution point to control whether to perform the update.

[0116] For Python code, the presence or absence of a dictionary key can be used to indicate the state of a field. If the generated code only controls the update based on whether the dictionary value is None, then when explicitly passing None in the request to clear the field, the intention to clear the field may be missed. In contrast, the correct generation method can use the presence or absence of the target key in the request dictionary as the basis for the update execution, and treat the dictionary value as the write value.

[0117] It should be noted that while the code syntax differs across programming languages, the verification objects in this application's embodiments remain consistent: all involve the state of a field being passed from sourceNode to sinkNode via processNode. For Java code, sourceNode, processNode, and sinkNode can be identified using abstract syntax trees, method call chains, and field reference relationships. For TypeScript, Go, or Python code, sourceNode, processNode, and sinkNode can be identified using syntax trees, symbol tables, object attribute access, dictionary key access, or text pattern matching. Although different languages ​​differ in their identification methods, this does not change the core logic of this application's embodiments in identifying state transmission anomalies based on state transmission information.

Claims

1. A code generation and verification method based on an interface field list, characterized in that, The method includes: obtaining a list of interface fields and a set of code files generated based on the list of interface fields; Based on the interface field list, determine the incremental update fields, which are fields that need to be distinguished between the state of not appearing and the state of appearing. The status transmission information corresponding to the incremental update field is constructed from the code file set. The status transmission information is used to characterize the transmission of the field occurrence status of the incremental update field from the status source position through the field processing position to the update execution position. Based on the status transmission information, determine whether the status of the field has been transmitted to the update execution location; In response to the fact that the field occurrence status is not passed to the update execution location, and the field occurrence status is replaced by the field value status in the code generation chain, it is determined that there is a status transmission anomaly in the incremental update field; based on the status transmission anomaly, a code generation verification result is generated.

2. The method according to claim 1, characterized in that, The step of determining the incremental update field based on the interface field list includes: obtaining the field path and field update semantic information from the interface field list; When the field update semantic information indicates that no update is performed when the field does not appear, and an update is allowed based on the field value when the field has appeared, the field corresponding to the field path is determined as the incremental update field.

3. The method according to claim 1, characterized in that, The state transmission information includes at least one of the following: field path, source node, processing node, target node, control dependency information, data dependency information, field value state substitution type, or code location. The source node represents the code node that carries the state of the field, the processing node represents the code node that reads, unpacks, assigns, maps, transforms, or updates the parameters of the incremental update field, and the target node represents the code node that performs the update write.

4. The method according to claim 3, characterized in that, The step of constructing the state transmission information corresponding to the incremental update field from the code file set includes: Based on the field path of the incremental update field, determine the request object code, field processing code, and update execution code from the code file set; The source node is determined from the request object code; the processing node is determined from the field processing code; the target node is determined from the update execution code. The state transmission information is constructed based on the reference relationships, assignment relationships, call relationships, or parameter passing relationships between the source node, the processing node, and the target node.

5. The method according to claim 4, characterized in that, Determining the target node from the update execution code includes: Based on at least one of the following: method name, annotation, field assignment statement, update call statement, update wrapper write call, repository interface save or update call, SQL update statement, dynamic SQL fragment or mapping file, determine the candidate update execution location; Based on at least one of the field path, field name, object attribute name, database column name, or field mapping configuration of the incremental update field, the candidate update execution position that can cause the data corresponding to the incremental update field to be written, overwritten, or cleared is determined as the target node.

6. The method according to claim 1, characterized in that, The step of determining whether the field's occurrence status has been passed to the update execution location based on the status transmission information includes: Based on at least one of control dependency, data dependency, method call parameter passing relationship, or update parameter binding relationship, determine whether the occurrence status of the field is passed to the update execution location; When the update execution position is controlled by the field occurrence status judgment, or the update execution position references intermediate status information generated by the field occurrence status, or the update execution position uses an update parameter object that retains the field occurrence status, it is determined that the field occurrence status is passed to the update execution position.

7. The method according to claim 6, characterized in that, The intermediate state information includes at least one of the following: field occurrence flag variable, boolean variable assigned by field occurrence state, object mapping field that retains field occurrence state, constructor parameter, builder parameter, optional wrapper object, nullable wrapper object, request field set, field binding record, reflection binding metadata, or update parameter object; Where the optional wrapper object only indicates whether a field value exists and cannot distinguish between the state where the field has not appeared and the state where the field has appeared, the optional wrapper object is not separately identified as the intermediate state information for retaining the state where the field has appeared.

8. The method according to claim 1, characterized in that, The field value status includes at least one of the following: whether the field value is empty, whether the field value is an empty string, whether the field value is an empty set, whether the field value is equal to a preset default value, whether the field value is equal to a preset unset placeholder value, or whether the field value wrapper object is empty. The field value status substitution includes: the update execution position uses the field value status as the basis for whether to perform the update write, rather than using the field occurrence status as the basis for whether to perform the update write.

9. The method according to claim 1, characterized in that, Before determining that there is an anomaly in the state transmission of the incremental update field in response to the fact that the field occurrence status is not transmitted to the update execution location and the field occurrence status is replaced by the field value status in the code generation chain, the method further includes: determining whether there is a misjudgment exclusion condition for the incremental update field. If the aforementioned misjudgment exclusion condition exists, it is uncertain whether the incremental update field exhibits the aforementioned state transmission anomaly. The conditions for excluding false positives include: the field value status judgment is only used for field value validity verification; the update execution location is controlled by the outer unified update strategy; the field occurrence status is passed to the update execution location through configuration files, annotations, interceptors, serialization binders or framework runtime mechanisms; or the field corresponding to the incremental update field belongs to at least one of the following: creation interface field, query interface field, full overwrite update field, response field or read-only field.

10. The method according to any one of claims 1 to 9, characterized in that, The step of generating code to generate verification results based on the state transmission anomaly includes: Generate a code generation verification result that includes at least one of the following: the field path of the incremental update field, the exception type of the status transmission exception, the code location of the source node, the code location of the processing node, the code location of the target node, or verification instructions. The method further includes: generating a verification result based on the code, generating a status transmission correction prompt message, wherein the status transmission correction prompt message is used to prompt that the field appearance status be retained in the generated code corresponding to the incremental update field, or to prompt that the update control basis of the update execution position be adjusted to the field appearance status.

Images