Complex object field dynamic management method based on serialization

Abstract

The invention provides a serialization-based complex object field dynamic management method, which relates to the technical field of data processing, and comprises the following steps: defining a dynamic field container based on explicit declarations in Java classes and core fields corresponding to JSON / YAML data structures, and not adding serialization framework annotations to the dynamic field container; according to a dynamic field container writing obtaining and setting method, automatically storing unidentified fields into a dynamic field container when deserialization is realized through a specific annotation, and outputting key value pairs in the dynamic field container as first-level fields during serialization; displaying the core field for displaying the declaration and the content in the dynamic field container in serialized output according to the priority, wherein the priority of the core field for displaying the declaration is greater than that of the content in the dynamic field container; and rewriting the consistency verification method, wherein the consistency verification method performs calculation only based on the core field.

Description

Technical Field

[0001] The present application belongs to the field of data processing technology, and specifically relates to a method for dynamic management of complex object fields based on serialization. Background Art

[0002] With the widespread adoption of microservice architectures and cloud-native technologies, JSON / YAML, as lightweight data exchange formats, plays a crucial role in distributed systems. In particular, the default integrated Jackson library in the Spring Boot framework has become the preferred tool for serialization and deserialization. However, existing technologies often face significant challenges when handling dynamic field expansion requirements (such as API version iterations and data transparent transmission across heterogeneous systems). Directly using mainstream serialization tools results in the discarding of unrecognized fields, resulting in data loss. This severely impacts the data integrity and flexibility of application scenarios such as log auditing and data transparent transmission.

[0003] Current technical implementations require developers to explicitly declare all possible fields, resulting in redundant code and increased maintenance costs. Furthermore, while using the @JsonIgnoreProperties annotation can avoid deserialization errors, it directly discards unrecognized fields, compromising the integrity of subsequent data analysis. Summary of the Invention

[0004] This application provides a method for dynamic management of complex object fields based on serialization to solve one of the above technical problems.

[0005] The technical solutions adopted in this application are: The present application provides a method for dynamically managing fields of complex objects based on serialization, including: Define dynamic field containers based on the core fields explicitly declared in the Java class corresponding to the JSON / YAML data structure. The dynamic field containers do not add serialization framework annotations. Write getter and setter methods based on the dynamic field container, use specific annotations to automatically store unrecognized fields into the dynamic field container during deserialization, and output the key-value pairs in the dynamic field container as first-level fields during serialization; The core fields of the display declaration and the contents of the dynamic field container are displayed in the serialized output according to their priority. The priority of the core fields of the display declaration is higher than the priority of the contents of the dynamic field container. Rewrite the consistency check method, which is calculated only based on core fields.

[0006] According to one embodiment of the present application, the dynamic field container is a key-value pair storage structure, wherein the key is a string type and the value is an arbitrary object type, and dynamic storage of unrecognized fields is achieved by initializing an empty Map structure. According to one embodiment of the present application, the specific annotations include deserialization annotations and serialization annotations, wherein the deserialization annotations are used to store the key-value pairs of unrecognized fields into a dynamic field container, and the serialization annotations are used to output the key-value pairs in the dynamic field container as first-level fields to the target JSON / YAML format.

[0007] According to one embodiment of the present application, the implementation of the priority depends on the default processing logic of the serialization framework. The default processing logic is that explicitly declared core fields take precedence over the content in the dynamic field container in the serialized output, and are arranged in sequence according to the declaration order of the core fields.

[0008] According to one embodiment of the present application, the processing logic of the serialization framework further includes ignoring explicit annotations of dynamic field containers during deserialization.

[0009] According to one embodiment of the present application, the explicit declaration of the core fields includes explicitly specifying the mapping relationship between the core fields and the JSON / YAML fields through annotations.

[0010] According to an embodiment of the present application, the priority control of the core fields further includes explicitly defining the output order of the core fields through attribute order control annotations.

[0011] According to an embodiment of the present application, the rewriting process of the consistency verification method includes: comparing only the values of the core fields in the equality judgment method, and generating the hash code only based on the values of the core fields in the hash code generation method.

[0012] A second aspect of the present application provides a computer-readable storage medium having a program stored thereon, which implements the steps in the method when executed by a processor.

[0013] In a third aspect, an embodiment of the present application provides an electronic device, including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor implements the steps in the method described above when executing the program.

[0014] Due to the adoption of the above technical solution, the beneficial effects achieved by this application are as follows: This application explicitly declares core fields and uses dynamic Map storage to ensure that even if unrecognized fields are encountered, they will exist as first-level fields in the serialized output, thereby maintaining consistency with the original data format.

[0015] All fields of this application (whether explicitly declared or unrecognized) can be fully stored in Java objects, which is particularly suitable for data auditing, transparent transmission and version compatibility scenarios where all information needs to be retained.

[0016] Application developers only need to focus on defining core business-related fields, eliminating the need to write additional code to accommodate unknown fields. Combined with dynamic proxy tools, field mapping logic can be automatically generated, further reducing manual coding workload.

[0017] This application supports iterative updates in JSON / YAML format. New fields can be seamlessly integrated without modifying existing code, which is particularly suitable for the coexistence of multiple versions of API in a microservice architecture.

[0018] This application excludes the additionalProperties field by default when rewriting the equality judgment method and hash code generation method to ensure that object comparison is based only on business core fields and avoid logical misjudgments due to unrecognized field changes. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings: Figure 1 A flowchart of a method for dynamically managing complex object fields based on serialization provided in an embodiment of the present application; Figure 2 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0020] Reference numerals: 810 , processor; 820 , communication interface; 830 , memory; 840 , communication bus. DETAILED DESCRIPTION

[0021] In order to more clearly illustrate the overall concept of the present application, a detailed description is given below in an illustrative manner in conjunction with the accompanying drawings.

[0022] The following description sets forth many specific details to facilitate a thorough understanding of the present application. However, the present application may also be implemented in other ways than those described herein, and therefore, the scope of protection of the present application is not limited by the specific embodiments disclosed below. It should be noted that the embodiments of the present application and the features of each embodiment may be combined with each other unless there is a conflict.

[0023] In this application, unless otherwise expressly specified and limited, a first feature "above" or "below" a second feature may be that the first and second features are in direct contact, or the first and second features are in indirect contact through an intermediate medium. In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in an appropriate manner in any one or more embodiments or examples.

[0024] Example 1 like Figure 1 As shown, a method for dynamic management of complex object fields based on serialization includes: S100. Based on the core fields explicitly declared in the Java class corresponding to the JSON / YAML data structure, a dynamic field container is defined, and the dynamic field container does not add serialization framework annotations.

[0025] As mentioned above, Java classes must explicitly declare "core fields" that directly correspond to JSON or YAML data structures. These core fields represent the most basic and indispensable units of information for data exchange. Furthermore, to address the possibility of unknown or newly added fields (i.e., fields not pre-declared in the Java class), a concept called a "dynamic field container" is introduced. This container is essentially a storage structure (such as a Map) specifically designed to hold these undeclared fields. Uniquely, this container lacks any annotations specific to the serialization framework. This allows it to flexibly accommodate unknown fields of various types and ensures that they are not ignored or lost during serialization and deserialization.

[0026] For example, consider a healthcare system that processes patient records, which include standard fields like "name," "age," and "gender," as well as extended fields like "vaccination status" that may change over time. Developers can first explicitly declare these core fields (i.e., "name," "age," and "gender") in a Java class, then leverage dynamic field containers to automatically capture and store all other undefined fields (e.g., "vaccination status"). This ensures that even when new, unknown fields are encountered during data exchange, they are not lost and are handled correctly, just like the original fields.

[0027] It's important to note that, in specific implementation scenarios, the above solution can be used to implement dynamic field containers that not only handle single-layer data structures but also support multi-level nested data formats. For example, when a JSON object contains another JSON object as its attribute value, this solution can recursively capture and store unrecognized fields at each level, ensuring the integrity and accuracy of the entire data structure.

[0028] In specific implementation scenarios, building on the above solution, to further enhance system flexibility, you can integrate type conversion logic into the dynamic field container. This means that regardless of the original data format (string, numeric, Boolean, etc.), it can be automatically adapted to the type required by the target data format, simplifying the developer's burden.

[0029] In specific implementation scenarios, a configuration option can be provided based on the above solution, allowing users to choose whether to enable the dynamic field container feature based on actual needs. This flexibility allows users to choose to ignore the additional fields in some strictly controlled data environments, while fully utilizing this feature in other situations to improve system compatibility and adaptability.

[0030] In specific implementation scenarios, based on the above solutions and taking into account the needs of large-scale data processing, lazy initialization or caching mechanisms can be introduced to reduce memory usage and improve serialization / deserialization efficiency. This helps maintain data integrity while reducing system resource consumption, which is particularly important in high-concurrency application scenarios.

[0031] In specific implementation scenarios, based on the above solution, this solution can also record the specific change points of each version and adjust the behavior mode of the dynamic field container accordingly to achieve seamless cross-version data integration and ensure data compatibility and consistency between different versions.

[0032] S200. Write getter and setter methods based on the dynamic field container, automatically store unrecognized fields into the dynamic field container during deserialization through specific annotations, and output the key-value pairs in the dynamic field container as primary fields during serialization.

[0033] As mentioned above, by defining a dynamic field container in a Java class and writing specific getter and setter methods for it, combined with the annotation mechanism of the serialization framework, automatic processing of unrecognized fields is achieved. Specifically, a dynamic field container (such as Map<String, String> )<String, Object> ) is used to store data that cannot be matched to explicitly declared fields during the deserialization process. To implement this functionality, you need to write two key methods for the dynamic field container: Get methods (such as getAdditionalProperties): By adding the @JsonAnyGetter annotation of the serialization framework, ensure that during serialization, the key-value pairs in the container are directly output as first-level fields in JSON / YAML rather than a nested structure.

[0034] Setting methods (such as setAdditionalProperty): By adding the @JsonAnySetter annotation of the deserialization framework, the framework automatically injects the key-value pairs of unrecognized fields into the dynamic field container when parsing the input data.

[0035] By combining the above method with annotations, the dynamic field container can automatically capture unknown fields during deserialization and output them in a flat format during serialization, ensuring the integrity and consistency of the data structure. This process requires no manual intervention from the developer, significantly reducing code complexity and avoiding the risk of data loss.

[0036] For example, consider the scenario where IoT devices report data. Assume the JSON data reported by the device contains core fields (such as "Device ID" and "Timestamp") and dynamically extended fields (such as "Sensor A Value" and "Sensor B Value"). In traditional solutions, if the "Sensor B Value" field is not predefined, it will be discarded during deserialization, resulting in incomplete data.

[0037] The developer explicitly declares "Device ID" and "Timestamp" as core fields in the Java class and defines a Map container (such as additionalProperties) without adding serialization annotations.

[0038] Through the @JsonAnySetter annotation, the deserializer will automatically store unknown fields such as "Sensor B Value" into the additionalProperties container.

[0039] During serialization, the @JsonAnyGetter annotation ensures that the key-value pairs in additionalProperties (such as "Sensor B Value") are directly output as first-level fields in JSON rather than being nested inside the container.

[0040] Ultimately, the output JSON data retains the core fields and fully includes the dynamically extended fields, meeting the needs of dynamic expansion of device data without the need to frequently modify Java class definitions.

[0041] It's important to note that, in specific implementation scenarios, the dynamic field container can extend beyond the aforementioned solution to handle single-level key-value pairs and recursively store nested objects or arrays. For example, if the input JSON contains nested fields (such as "Sensor A value.subfield"), the container can convert it into a nested Map structure through recursive parsing logic and output it in the corresponding nested format during serialization. This is suitable for transparent transmission of complex data structures, such as the multi-level diagnostic results contained in patient examination reports in medical systems.

[0042] In specific implementation scenarios, building on the above solution, you can also integrate type conversion logic into the dynamic field container's setup method. For example, when input data is a string value (such as "123"), it can be automatically converted to the target data type (such as Integer), and vice versa. This improves data compatibility and avoids deserialization failures due to type mismatches, making it particularly suitable for data exchange between heterogeneous systems.

[0043] In specific implementation scenarios, the above solution can be supplemented with runtime configuration options, allowing developers to dynamically enable or disable the dynamic field container. For example, in strict validation scenarios, the container can be disabled to ensure only explicitly declared fields are processed; in flexible scalability scenarios, the container can be enabled to retain all unknown fields. This can adapt to different business needs, such as financial system compliance validation, which requires strict field limits, while data analysis scenarios require retaining all fields for subsequent processing.

[0044] In specific implementation scenarios, the above solution can be combined with lazy initialization or caching to reduce the memory usage of dynamic field containers. For example, during deserialization, the container can be initialized only upon the first encounter of an unknown field, avoiding unnecessary resource consumption. This is suitable for highly concurrent systems, such as real-time monitoring platforms, which must process massive amounts of device data and balance data integrity with system performance.

[0045] In specific implementation scenarios, the above solution can be combined with the API version number to dynamically adjust the behavior of dynamic field containers. For example, a specific field can be ignored in the old API version, but included in the container processing in the new version, achieving cross-version data compatibility. This supports the coexistence of multiple API versions in a microservice architecture, ensuring seamless integration of historical data and new features, such as the iteration of the order interface of an e-commerce platform.

[0046] S300: Display the core fields of the display declaration and the content in the dynamic field container in the serialized output according to their priorities. The priority of the core fields of the display declaration is higher than the priority of the content in the dynamic field container.

[0047] As mentioned above, explicitly declared core fields (such as those bound via the @JsonProperty annotation in Java classes) are given the highest priority during serialization. These fields are arranged in the order in which they are declared in the Java class in the output, ensuring that key information is highlighted.

[0048] Complementarity of dynamic field containers: Dynamic field containers (such as Map<String, Object> Type) is used to store fields that are not explicitly declared during the deserialization process. Although these fields may have business significance in data processing, they will be output after all core fields during serialization to avoid interfering with the logical priority of core fields.

[0049] Implementation: Control the output order of fields through the serialization framework's default behavior (such as Jackson's property order control annotations) or explicit configuration. For example, the output order of core fields is determined by their definition order in the class, while the contents of dynamic field containers are output through the @JsonAnyGetter annotation and, by default, are placed after explicit fields in the serialization framework's processing logic.

[0050] For example, consider an e-commerce platform that needs to process order information, which includes core fields such as "Order ID," "Customer Name," and "Order Date," as well as additional fields such as "Promotion Code" and "Logistics Tracking Number," which may change over time or be added to meet different business needs. According to the method of the present invention, during the serialization process, core fields such as "Order ID," "Customer Name," and "Order Date" will appear first in the JSON / YAML output in a predefined order, while fields that are not explicitly declared, such as "Promotion Code" and "Logistics Tracking Number," will be listed after all core fields. This approach not only ensures that key information is highlighted but also leaves room for possible future field expansion, making the entire system more flexible and easier to maintain.

[0051] It's important to note that, in specific implementation scenarios, developers can also build on the above solution by explicitly defining the output order of core fields through configuration files or annotations (such as @JsonPropertyOrder). For example, in a medical system, "Patient ID" could be placed first, followed by "Diagnosis Date" to meet business logic requirements. This approach is suitable for industry scenarios that require strict adherence to a specific field order (such as financial transaction records and government approval processes), ensuring standardized data formats.

[0052] In specific implementation scenarios, the above solution can also be used to dynamically adjust the display order of fields based on different language environments (such as Chinese and English). For example, "Product Name" can be prioritized in a Chinese interface, while "Product Name" can be prioritized in an English interface. This supports international product design and improves user experience, especially in cross-cultural business systems (such as cross-border e-commerce platforms).

[0053] In specific implementation scenarios, the above solution can be supplemented with a runtime configuration switch to allow for temporary adjustment of field priorities based on business needs. For example, when processing urgent orders, the "Emergency Flag" field can be elevated above core fields for faster identification. This approach is suitable for scenarios that require flexible response to external conditions (such as disaster emergency response systems and real-time monitoring platforms), improving system adaptability.

[0054] In specific implementation scenarios, you can also build on the above solution by setting different field priority strategies for different API versions. For example, you can maintain the original field order in the old API version, while redefining the priority of core fields in the new version based on business needs. This supports the coexistence of multiple versions in a microservices architecture, ensuring seamless integration of historical data and new features (such as interface upgrades for banking systems).

[0055] In specific implementation scenarios, building on the above solution, you can also introduce a lazy initialization or caching mechanism into the dynamic field container to reduce memory usage. For example, you can initialize the container only when an unknown field is first encountered, avoiding unnecessary resource consumption. This is suitable for highly concurrent systems (such as real-time data collection platforms), ensuring data integrity while reducing system overhead.

[0056] In specific implementation scenarios, the above solution can be used to prioritize fields within nested objects. For example, in a nested JSON structure, subfields of core fields are output before subfields of dynamic fields. This approach is suitable for processing complex data structures (such as multi-level order data in supply chain management systems), ensuring readability and logical clarity of nested data.

[0057] S400: Rewrite the consistency check method so that the consistency check method performs calculations based only on core fields.

[0058] As mentioned above, dynamic field containers are used to store unrecognized or extended fields, which may change frequently due to external input changes. Including these fields in consistency checking logic can lead to unstable object comparison results and even false positives. By calculating consistency based only on core fields, the stability of the verification logic is ensured.

[0059] Core fields typically represent an object's unique identifier or key business attributes (such as order ID or user ID). Validating based solely on these fields accurately reflects the object's actual meaning in the business scenario and avoids logical errors caused by temporary changes to dynamic fields.

[0060] Many serialization frameworks (such as Jackson) store unrecognized fields in dynamic containers by default. Failure to proactively exclude these fields can cause equality checks and hash code generation methods to misidentify objects as inconsistent due to field differences, impacting features that rely on consistency checks, such as caching and collection operations.

[0061] Rewrite the equality judgment method: only compare the values of explicitly declared core fields and ignore the contents of dynamic field containers.

[0062] Rewrite the hash code generation method: Generate hash codes based only on the values of core fields to ensure that the same object maintains the same hash value in different serialization / deserialization operations.

[0063] Configure framework behavior: Ensure that dynamic field containers do not participate in object identity calculations through serialization framework configuration (such as Jackson's @JsonInclude annotation).

[0064] For example, taking an IoT device management platform as an example, assume that the device object contains the following fields: Core fields: device ID, device type, installation time (these fields are explicitly declared in the Java class).

[0065] Dynamic fields: sensor data, operating status (these fields may change in real time with the device status and are not predefined in the Java class).

[0066] Deserialization phase: When reading device information from JSON data, the device ID, device type, and installation time are mapped to core fields, while sensor data and operating status are automatically stored in dynamic field containers.

[0067] Consistency check phase: If two device objects have exactly the same device ID, device type, and installation time, but different sensor data or operating status, the equality judgment method will still determine that the two are consistent.

[0068] Business impact: In the device management system's cache or database queries, this validation logic ensures that the uniqueness of device objects is determined only by core fields, preventing duplicate storage or incorrect matching due to temporary differences in dynamic fields.

[0069] For example, if device A's sensor data is "Temperature: 25°C" and device B's sensor data is "Temperature: 26°C," but both have the same device ID and installation time, they are considered the same device object. This design meets business requirements because the core identity of the device (ID and installation time) remains unchanged, and differences in dynamic fields do not affect object consistency.

[0070] It should be noted that in specific implementation scenarios, based on the above solution, during API version iteration, the old version interface may lack core fields in the new version. By dynamically adjusting the field dependencies of the equality judgment method and the hash code generation method, consistency verification of objects across versions can be achieved. For example, in the old version API, verification was based only on the "device ID", while the new version adds the "device type" as a verification field. This is suitable for multi-version coexistence scenarios in microservice architectures to ensure the compatibility of historical data and new functions.

[0071] In specific implementation scenarios, based on the above solution, you can also provide a configuration option, allowing developers to decide at runtime whether to include dynamic fields in consistency checks. For example, dynamic field checks can be enabled in debug mode for troubleshooting, but disabled in production to improve performance. This is suitable for scenarios that require flexible switching of verification strategies (such as different requirements between development and production environments).

[0072] In specific implementation scenarios, building on the above solution, a caching mechanism can be introduced into the hash code generation method to recalculate the hash value only when core fields change, avoiding repeated calculations. For example, by recording the last modification time of a core field, the hash code can be updated only when a change is detected. This approach is suitable for highly concurrent systems (such as real-time monitoring platforms), reducing resource consumption during hash calculations and improving system performance.

[0073] In specific implementation scenarios, the above solution can be combined with digital signatures or hash verification to ensure that the contents of dynamic field containers have not been tampered with. For example, a digest of the dynamic field can be generated during serialization and its integrity verified during deserialization. This is suitable for sensitive data processing scenarios (such as financial transactions and medical systems) to prevent data contamination caused by malicious modification of dynamic fields.

[0074] In specific implementation scenarios, you can also build on the above solution by recording field version information (such as the API version number) in the dynamic field container and using this version number to decide whether to ignore specific fields during consistency checks. For example, if a dynamic field in an older API version is deprecated in a newer version, its impact on the verification result can be automatically eliminated. This approach is suitable for long-term evolving systems (such as enterprise applications) and ensures data consistency between different versions without being affected by deprecated fields.

[0075] In specific implementation scenarios, the above solution can be used to support layered consistency validation logic within nested objects. For example, if a dynamic field container contains nested objects (such as "sensor data.temperature"), validation rules can be recursively applied, prioritizing the core field to ensure the stability of the nested structure. This is suitable for validating complex data structures (such as multi-level order data in a supply chain management system), preventing changes in nested fields from affecting overall consistency.

[0076] In some embodiments of the present application, the dynamic field container is a key-value pair storage structure, wherein the key is a string type and the value is an arbitrary object type, and dynamic storage of unrecognized fields is achieved by initializing an empty Map structure. As mentioned above, the dynamic field container is designed as a key-value storage structure specifically for storing fields that are not predefined during serialization or deserialization. This design ensures that even when encountering unknown or newly added fields, the system can automatically adapt and save this data without causing data loss.

[0077] Specifically, the dynamic field container is implemented using a Map structure, where: Key: A string type representing the name of a field. For example, in a JSON object, field names such as "name" and "age" will be stored as keys in the Map.

[0078] Value: can be any object type, which means it can store a variety of different types of data, such as strings, numbers, Booleans, arrays, and even nested objects. This provides great flexibility, allowing dynamic field containers to handle complex data structures of different formats and types.

[0079] When a Java class instance is created, the dynamic field container is initialized as an empty Map. This means that it initially contains no data. Only during deserialization, if data items are encountered that do not match explicitly declared fields in the Java class, are these items automatically stored in the dynamic field container. Similarly, during serialization, all key-value pairs in the dynamic field container are output, ensuring the integrity and accuracy of the original data.

[0080] The benefit of this approach is that developers don't need to know all possible field names and types in advance, nor do they need to write additional code for each possible extension field. By leveraging dynamic field containers, the system can automatically adapt to data changes, reducing maintenance costs and increasing system flexibility and scalability. Furthermore, because dynamic field containers do not restrict the type of data they store, they can easily handle a variety of complex business scenarios and meet the needs of different applications.

[0081] In some embodiments of the present application, the specific annotations include deserialization annotations and serialization annotations, wherein the deserialization annotations are used to store the key-value pairs of unrecognized fields into a dynamic field container, and the serialization annotations are used to output the key-value pairs in the dynamic field container as first-level fields to the target JSON / YAML format.

[0082] As mentioned above, the main purpose of deserialization annotations is to automatically store key-value pairs of unrecognized fields in the dynamic field container. When deserializing data from JSON or YAML format, if some fields cannot be matched with the properties explicitly declared in the Java class, these fields are considered unrecognized fields. By using deserialization annotations (such as @JsonAnySetter), you can specify a method to receive and store these unrecognized fields. Specifically: When an unrecognized field is encountered during deserialization, the name of the field is used as the key and the value of the field is used as the value, and the two together are passed to the specified method as a key-value pair.

[0083] This method is responsible for storing the received key-value pairs into a dynamic field container (such as Map<String, Object> This way, even if these fields are not predefined in the Java class, they can be saved, avoiding data loss.

[0084] Serialization annotations are used to ensure that during serialization, all key-value pairs in the dynamic field container are output as first-level fields to the target JSON or YAML format. This means that when converting a Java object back to JSON or YAML format, not only will the explicitly declared core fields be included in the output, but all contents in the dynamic field container will also appear in the final output at the same level. This is usually achieved by using serialization annotations (such as @JsonAnyGetter): During the serialization phase, the method annotated with @JsonAnyGetter is called, which returns the content of the dynamic field container.

[0085] This content is then processed by the serialization framework and added as first-level fields to the final generated JSON or YAML document. This ensures that the data in the dynamic field container is correctly processed during both deserialization and serialization, maintaining the integrity and consistency of the data structure.

[0086] In some embodiments of the present application, the implementation of the priority depends on the default processing logic of the serialization framework. The default processing logic is that explicitly declared core fields take precedence over the contents in the dynamic field container in the serialized output, and are arranged in sequence according to the declaration order of the core fields.

[0087] As mentioned above, the core of the priority mechanism is that explicitly declared core fields have higher priority in serialization output and are arranged in the order in which they are declared in the Java class. Specifically: Explicitly declared core fields take precedence: When serializing, explicitly declared core fields (i.e., those explicitly bound to JSON or YAML fields through annotations such as @JsonProperty) are processed and output first by the serialization framework. This means that these fields appear at the very beginning of the generated JSON or YAML document.

[0088] Arrange in declaration order: Explicitly declared core fields are not only output first, but also arranged strictly in the order in which they are declared in the Java class. For example, if a Java class first declares the "name" field and then the "age" field, then during serialization output, the "name" field will appear before the "age" field.

[0089] Dynamic field container content is second: Dynamic field container (such as Map<String, Object> Type) is used to store additional fields that are not explicitly declared during deserialization. During serialization, these key-value pairs stored in the dynamic field container are output after all explicitly declared core fields. This is done to avoid interfering with the main information displayed by the core fields while also ensuring data integrity and flexibility.

[0090] This prioritization mechanism relies entirely on the serialization framework's default processing logic, requiring no additional manual configuration or complex logic adjustments. Based on how the fields are defined, the serialization framework automatically identifies which fields are core fields and which should be retrieved and output from the dynamic field container. This design simplifies the developer's workload while ensuring consistent and predictable data output formats.

[0091] In some embodiments of the present application, the processing logic of the serialization framework further includes ignoring explicit annotations of dynamic field containers during deserialization.

[0092] As mentioned above, the serialization framework's processing logic specifically considers how to handle data in dynamic field containers to ensure flexibility and adaptability. The following is a detailed description: Ignore explicit annotations on dynamic field containers: When deserializing, the serialization framework automatically ignores any explicit annotations (such as @JsonProperty) applied to dynamic field containers. This means that the key-value pairs in the dynamic field container are not affected or restricted by these annotations. For example, if a field exists in the JSON data but is not predefined in the Java class, it will be stored directly in the dynamic field container without matching any specific annotations.

[0093] Role of dynamic field container: Dynamic field container (such as Map<String, Object> Type) is used to store fields that are not explicitly declared during the deserialization process. Because the presence of explicit annotations is ignored, no matter how many unknown or newly added fields the input data contains, they can be automatically captured and stored in the dynamic field container without causing deserialization failures or data loss.

[0094] Maintaining Flexibility: By omitting explicit annotations on dynamic field containers, this invention enhances system flexibility. Developers don't need to know all possible field names or types in advance, nor do they need to add additional annotations or modify code for each potential new field. This allows the system to easily adapt to changes in data structures, which is particularly important in scenarios such as API version iterations or data exchange between heterogeneous systems.

[0095] Simplified development process: This design simplifies the developer's workload, as they only need to focus on the definition of core fields and their corresponding business logic. For unknown fields, they can simply be stored in the dynamic field container, without the need for additional configuration or complex logic adjustments.

[0096] In some embodiments of the present application, the explicit declaration of the core fields includes explicitly specifying the mapping relationship between the core fields and the JSON / YAML fields through annotations.

[0097] As mentioned above, explicit declaration of core fields means defining specific properties in a Java class and using annotations to make it clear how these properties correspond to fields in external data formats (such as JSON or YAML documents). The specific implementation is as follows: The role of annotations: By using annotations (such as @JsonProperty in the Jackson library), developers can precisely specify which field in a JSON or YAML document a property in a Java class should correspond to. This mapping is crucial for ensuring data consistency and accuracy.

[0098] For example, in a Java class representing user information, there is a property called userName, while the corresponding JSON data field may be named username. To ensure that this field is correctly identified and processed during serialization and deserialization, you can add the @JsonProperty("username") annotation to the userName property to establish a mapping relationship between the two.

[0099] Ensure mapping accuracy: Explicitly declared core fields are not limited to simple name mappings but can also include more complex configuration options, such as specifying date formats, whether to ignore unknown fields, etc. This helps resolve data parsing issues caused by naming differences or different data formats.

[0100] For example, if the date field format in the JSON data is "yyyy-MM-dd" and the java.util.Date type is used in the Java class, the date format can be further specified through annotations to ensure correct conversion.

[0101] Simplified data processing: By explicitly declaring core fields and their mapping to external data formats, developers can more easily handle various data exchange scenarios and reduce the need to manually write conversion logic. This is very helpful for improving development efficiency and reducing error rates.

[0102] Enhanced system flexibility and maintainability: When data structures need to be modified or expanded, only the corresponding annotation configuration needs to be adjusted, without the need for large-scale code refactoring. This design makes the system more flexible and easier to maintain and upgrade.

[0103] In some embodiments of the present application, the priority control of the core fields further includes explicitly defining the output order of the core fields through attribute order control annotations.

[0104] As mentioned above, the priority control of core fields is not limited to ensuring that core fields have a higher priority in the serialized output than the contents of the dynamic field container, but also includes precise control of the specific output order of these core fields through specific annotations (such as @JsonPropertyOrder). The following is a detailed explanation: Use the property order control annotation: This annotation can be applied directly to a Java class to specify the output order of all serialized fields (i.e., core fields) in that class. Developers can specify the position of each field in the serialized output by listing the field names. For example, in a Java class containing multiple properties, if you want the "order ID" field to always be before the "customer name" field, you can add the @JsonPropertyOrder({"orderId", "customerName"}) annotation above the class definition.

[0105] Ensure sequential consistency: This ensures that core fields are output in the specified order regardless of the environment in which the serialization operation is performed. This is particularly important for scenarios where data format consistency is required, such as cross-system data exchange, logging, or database persistence, ensuring a standardized and predictable output format.

[0106] Flexibility and Extensibility: While @JsonPropertyOrder is primarily used to define a fixed order, in some cases it can be combined with other annotations or configuration options to implement more complex sorting logic. For example, you can dynamically adjust the order of fields based on business needs or define different field sorting rules for different API versions. This flexibility allows the system to better adapt to changes and meet the needs of diverse application scenarios.

[0107] Improved readability and maintainability: Explicitly specifying the output order of fields helps improve the readability of the generated data structure, making it easier to process and analyze. Furthermore, this simplifies code maintenance because once the field order is determined, there's no need to worry about issues caused by changes to the data structure, reducing debugging and maintenance costs.

[0108] In some embodiments of the present application, the rewriting process of the consistency verification method includes: only comparing the values of the core fields in the equality judgment method, and only generating the hash code based on the values of the core fields in the hash code generation method.

[0109] As mentioned above, rewriting the consistency check method involves modifying the equality check method and the hash code generation method so that they only consider the explicitly declared core fields and completely ignore the contents of the dynamic field container. The following are detailed steps: Only the values of core fields are compared in the equality check method, ensuring that two objects are considered equal only if their core fields have the same values, regardless of whether the contents of their dynamic field containers are the same.

[0110] First, check whether the two objects are the same instance (that is, the memory address is the same). If so, return true directly.

[0111] Then check if the other object is null, or is of the same class, and if not, return false.

[0112] Next, the values of all explicitly declared core fields are compared one by one. If the values of all core fields are equal, true is returned; otherwise, false is returned.

[0113] The contents of the dynamic field container do not participate in the comparison process, which means that even if two objects have different dynamic fields, the two objects are considered equal as long as the core fields match.

[0114] In the hash code generation method, hash codes are generated only based on the values of core fields, ensuring that the hash code of each object depends only on the values of its core fields. This can avoid frequent changes in hash codes due to changes in dynamic fields, which in turn affects the performance and correctness of set operations (such as HashSet and HashMap).

[0115] Hash code is calculated using a reliable algorithm (such as Objects.hash() method in Java) that accepts multiple parameters and generates an integer hash code based on those parameters.

[0116] Only explicitly declared core fields are passed as parameters to the hash code generation algorithm, without data from any dynamic field containers.

[0117] In this way, even if the content in the dynamic field container changes, as long as the core fields remain unchanged, the hash code of the object will not change, ensuring the consistency and efficiency of collection operations.

[0118] An embodiment of a second aspect of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method of any one of the embodiments of the first aspect when executing the program.

[0119] Figure 2 An example of a physical structure diagram of an electronic device is shown below. Figure 2 As shown, the electronic device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 may call the logic instructions in the memory 830 to execute the method in any embodiment of the first aspect above, the method including: Define dynamic field containers based on the core fields explicitly declared in the Java class corresponding to the JSON / YAML data structure. The dynamic field containers do not add serialization framework annotations. Write getter and setter methods based on the dynamic field container, use specific annotations to automatically store unrecognized fields into the dynamic field container during deserialization, and output the key-value pairs in the dynamic field container as first-level fields during serialization; The core fields of the display declaration and the contents of the dynamic field container are displayed in the serialized output according to their priority. The priority of the core fields of the display declaration is higher than the priority of the contents of the dynamic field container. Rewrite the consistency check method, which is calculated only based on core fields.

[0120] Furthermore, the logic instructions in the aforementioned memory 830 can be implemented as software functional units and, when sold or used as standalone products, stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the portion that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product, stored in a storage medium, includes instructions for causing a computer device (such as a personal computer, server, or network device) to execute all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memories, random access memories, magnetic disks, or optical disks.

[0121] On the other hand, the present invention further provides a computer program product, comprising a computer program. The computer program may be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can perform the method provided by each of the above methods, including: Define dynamic field containers based on the core fields explicitly declared in the Java class corresponding to the JSON / YAML data structure. The dynamic field containers do not add serialization framework annotations. Write getter and setter methods based on the dynamic field container, use specific annotations to automatically store unrecognized fields into the dynamic field container during deserialization, and output the key-value pairs in the dynamic field container as first-level fields during serialization; The core fields of the display declaration and the contents of the dynamic field container are displayed in the serialized output according to their priority. The priority of the core fields of the display declaration is higher than the priority of the contents of the dynamic field container. Rewrite the consistency check method, which is calculated only based on core fields.

[0122] In another aspect, the present invention further provides a non-transitory computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the method for cigarette box image recognition provided by the above methods is implemented, and the method includes: Define dynamic field containers based on the core fields explicitly declared in the Java class corresponding to the JSON / YAML data structure. The dynamic field containers do not add serialization framework annotations. Write getter and setter methods based on the dynamic field container, use specific annotations to automatically store unrecognized fields into the dynamic field container during deserialization, and output the key-value pairs in the dynamic field container as first-level fields during serialization; The core fields of the display declaration and the contents of the dynamic field container are displayed in the serialized output according to their priority. The priority of the core fields of the display declaration is higher than the priority of the contents of the dynamic field container. Rewrite the consistency check method, which is calculated only based on core fields.

[0123] Anything not described in this application can be achieved by adopting or drawing on existing technologies.

[0124] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments.

[0125] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims

1. A method for dynamic management of complex object fields based on serialization, characterized in that: include: Define dynamic field containers based on the core fields explicitly declared in the Java class corresponding to the JSON / YAML data structure. The dynamic field containers do not add serialization framework annotations. Write getter and setter methods based on the dynamic field container, use specific annotations to automatically store unrecognized fields into the dynamic field container during deserialization, and output the key-value pairs in the dynamic field container as first-level fields during serialization; The core fields of the display declaration and the contents of the dynamic field container are displayed in the serialized output according to their priority. The priority of the core fields of the display declaration is higher than the priority of the contents of the dynamic field container. Rewrite the consistency check method, which is calculated only based on core fields.

2. The method according to claim 1, characterized in that The dynamic field container is a key-value pair storage structure, where the key is a string type and the value is an arbitrary object type. Dynamic storage of unrecognized fields is achieved by initializing the Map structure to an empty one.

3. The method according to claim 1, characterized in that The specific annotations include deserialization annotations and serialization annotations, wherein the deserialization annotations are used to store the key-value pairs of unrecognized fields into the dynamic field container, and the serialization annotations are used to output the key-value pairs in the dynamic field container as first-level fields to the target JSON / YAML format.

4. The method according to claim 1, wherein The implementation of the priority depends on the default processing logic of the serialization framework. The default processing logic is that explicitly declared core fields take precedence over the contents of the dynamic field container in the serialized output, and are arranged in the order in which the core fields are declared.

5. The method according to claim 4, characterized in that The processing logic of the serialization framework also includes ignoring explicit annotations of dynamic field containers during deserialization.

6. The method according to claim 1, characterized in that The explicit declaration of the core fields includes explicitly specifying the mapping relationship between the core fields and the JSON / YAML fields through annotations.

7. The method according to claim 1, characterized in that The priority control of the core fields also includes explicitly defining the output order of the core fields through attribute order control annotations.

8. The method according to claim 7, characterized in that The rewriting process of the consistency check method includes: comparing only the values of the core fields in the equality judgment method, and generating the hash code based only on the values of the core fields in the hash code generation method.

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

10. An electronic device comprising a memory, a processor, and a program stored in the memory and executable on the processor, wherein: When the processor executes the program, the steps in the method according to any one of claims 1 to 8 are implemented.

Images