Object relation mapping-oriented entity class dynamic management system and method and medium

Abstract

The invention discloses an object relation mapping-oriented entity class dynamic management system and method and a medium. Comprises: a change monitoring module configured to notify an entity class management framework when a table structure change event is monitored; the entity class management framework is configured to obtain changed table structure metadata from metadata storage when receiving a notification of changing the monitoring module, call a byte code generation engine to generate a byte code of a first version entity class, and load the byte code of the first version entity class through a user-defined class loader; after the first version entity class is successfully loaded, the object relation mapping framework is notified to update a metadata model of the object relation mapping framework to reconstruct an internal mapping relation, and version information of a corresponding table structure in metadata storage is updated; and returning the target version entity class matched with the version indication information to the service system initiating the request. According to the method and the device, the entity class can be updated to adapt to database table structure change under the condition that the application service is not restarted.

Description

Technical Field

[0001] This application relates to the field of computer software technology, particularly to the field of database management technology, and especially to a dynamic management system, method, device, medium, and product for entity classes using object-oriented relational mapping. Background Technology

[0002] In modern software development, Object Relational Mapping (ORM) frameworks are widely used. By mapping database tables to entity classes in programming languages, they greatly simplify data persistence operations and improve development efficiency.

[0003] However, traditional ORM frameworks have a significant technical drawback: the definition of entity classes is statically bound to the database table structure. When the application starts, the ORM framework loads the mapping metadata based on the pre-compiled entity class code. Once the database table structure (schema) changes—for example, by adding, deleting, or modifying fields—the corresponding entity class code must also be manually modified, recompiled, and repackaged for deployment; in other words, the entire application must be restarted for the changes to take effect.

[0004] In the current context of agile development and continuous integration / continuous deployment (CI / CD), database schema changes are becoming increasingly frequent. Frequent restarts of application services in production environments lead to service interruptions, impacting user experience and increasing operational complexity and risk. While database version management tools such as Flyway and Liquibase exist, they fail to address the dynamic synchronization issue between application runtime entity classes and database table structures. Therefore, there is an urgent need for a technical solution that can automatically and dynamically update entity classes to adapt to changes in database table structures without restarting application services. Summary of the Invention

[0005] In view of this, embodiments of this application provide a dynamic management system, method, device, medium, and product for entity classes based on object-oriented relational mapping, which can update entity classes to adapt to changes in database table structure without restarting application services.

[0006] In a first aspect, embodiments of this application provide a dynamic entity class management system for object-oriented relational mapping. This system includes a change monitoring module, an entity class management framework, a bytecode generation engine, a custom class loader, metadata storage, and an object-relational mapping framework. The change monitoring module is configured to monitor data definition language operations on database table structures and notify the entity class management framework when a table structure change event is detected. The entity class management framework is configured to, upon receiving notification from the change monitoring module regarding a database table, retrieve the changed table structure metadata from the metadata storage, call the bytecode generation engine to dynamically generate bytecode for a first version entity class of the database table based on the table structure metadata, and load the bytecode of the first version entity class through a custom class loader. The custom class loader is configured to create a class corresponding to the first version entity class. The loading space allows the first and second version entity classes associated with the database table to coexist at runtime, with the second version entity class being the older version entity class already loaded in the database table. The entity class management framework is also configured to, after successfully loading the first version entity class of the database table, notify the object-relational mapping framework to update its metadata model, enabling the object-relational mapping framework to rebuild its internal mapping relationships to identify and use the first version entity class, and update the version information of the corresponding table structure in the metadata store. The entity class management framework is also configured to receive entity class retrieval requests from business systems for database tables, and based on the version indication information corresponding to the entity class retrieval request, determine the target version entity class matching the version indication information from multiple version entity classes associated with the database table, and return the target version entity class to the requesting business system.

[0007] Secondly, embodiments of this application provide a dynamic management method for entity classes using object-relational mapping, for use in a dynamic entity class management system. This system includes a change monitoring module, an entity class management framework, a bytecode generation engine, a custom class loader, metadata storage, and an object-relational mapping framework. The method includes: the change monitoring module monitoring data definition language operations on the database table structure and notifying the entity class management framework when a table structure change event is detected; upon receiving notification from the change monitoring module regarding the database table, the entity class management framework retrieves the changed table structure metadata from the metadata storage, calls the bytecode generation engine to dynamically generate bytecode for a first version of the entity class of the database table based on the table structure metadata, and loads the bytecode of the first version entity class through a custom class loader; the custom class loader creates the first version... The class loading space corresponding to the entity class allows the first and second version entity classes associated with the database table to coexist at runtime, with the second version entity class being the older version entity class already loaded in the database table. After successfully loading the first version entity class of the database table, the entity class management framework also notifies the object-relational mapping framework to update its metadata model, enabling the object-relational mapping framework to rebuild its internal mapping relationships to identify and use the first version entity class, and update the version information of the corresponding table structure in the metadata store. The entity class management framework also receives entity class retrieval requests from business systems for database tables, and based on the version indication information corresponding to the entity class retrieval request, determines the target version entity class that matches the version indication information from multiple version entity classes associated with the database table, and returns the target version entity class to the requesting business system.

[0008] Thirdly, embodiments of this application provide an electronic device, including: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements the steps of the object-oriented relational mapping entity class dynamic management method as described in the second aspect.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the steps of the object-oriented relational mapping entity class dynamic management method as described in the second aspect.

[0010] Fifthly, embodiments of this application provide a computer program product, which is stored in a non-volatile storage medium, and when executed by a processor, the computer program product implements the steps of the object-oriented relational mapping entity class dynamic management method as described in the second aspect.

[0011] In a sixth aspect, embodiments of this application provide a chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the steps of the object-oriented relational mapping entity class dynamic management method as described in the second aspect.

[0012] This application provides a dynamic entity class management system, method, device, medium, and product for object-relational mapping (ORM). By introducing a collaborative architecture comprising a change monitoring module, an entity class management framework, a bytecode generation engine, a custom class loader, metadata storage, and an ORM framework, it solves the technical problem of traditional ORM frameworks requiring application service restarts due to the static binding of entity classes to database table structures. Specifically, the change monitoring module continuously monitors DDL changes to the database table structure and triggers an update process upon detection, enabling the system to respond to database changes in real time. The bytecode generation engine dynamically generates bytecode for new version entity classes based on the latest table structure metadata obtained from the metadata storage. Combined with an independent class loading space created by the custom class loader, it achieves runtime coexistence of old and new version entity classes, thus avoiding the need to stop application services to update entity classes. The entity class management framework receives entity class retrieval requests from business systems and accurately routes the target entity class from multiple coexisting versions based on version indication information, ensuring seamless operation of business logic during the transition period of database table structure changes. Simultaneously, the framework notifies the ORM framework to update its metadata model, enabling it to rebuild its internal mapping relationships to identify new version entity classes, ensuring the accuracy of data persistence operations. Thus, this solution enables "hot updates" of entity classes through a custom class loading mechanism in agile development and CI / CD environments where database schemas change frequently. After the database table structure changes, the application can take effect without restarting, reducing service interruption time, lowering operational complexity and risk, and ultimately achieving high availability and continuity of application services, thus ensuring service continuity and high availability. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings of the embodiments of this application will be briefly described below.

[0014] Figure 1 This is a schematic diagram of the structure of an object-oriented relational mapping entity class dynamic management system provided in an embodiment of this application; Figure 2 This is an exemplary schematic diagram of the dynamic management process of entity classes in object-oriented relational mapping provided in an embodiment of this application; Figure 3 This is an exemplary schematic diagram of the dynamic management process of entity classes in object-oriented relational mapping provided in another embodiment of this application; Figure 4This is an exemplary schematic diagram of the dynamic management process of entity classes in object-oriented relational mapping provided in another embodiment of this application; Figure 5 This is an exemplary schematic diagram of the dynamic management process of entity classes in object-oriented relational mapping provided in another embodiment of this application; Figure 6 This is a flowchart illustrating an embodiment of the object-oriented relational mapping method for dynamic management of entity classes. Figure 7 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0015] The principles and spirit of this application will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided to make the principles and spirit of this application clearer and more thorough, enabling those skilled in the art to better understand and implement the principles and spirit of this application. The exemplary embodiments provided herein are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments described herein without inventive effort are within the scope of protection of this application.

[0016] In this document, terms such as first, second, and third are used only to distinguish one entity (or operation) from another entity (or operation), and are not intended to require or imply any order or relationship between these entities (or operations).

[0017] The following description, in conjunction with the accompanying drawings, details the object-oriented relational mapping entity class dynamic management system and method provided in this application through specific embodiments and application scenarios.

[0018] Figure 1 This is a schematic diagram of the structure of an entity class dynamic management system for object-oriented relational mapping provided in an embodiment of this application. The entity class dynamic management system can be simply referred to as the "system".

[0019] like Figure 1 As shown, the system 100 may include a change monitoring module 101, an entity class management framework 102, a bytecode generation engine 103, a custom class loader 104, a metadata storage 105, and an object-relational mapping framework 106. Among them, the change monitoring module 101 is configured to monitor data definition language operations on the database table structure and notify the entity class management framework when a table structure change event is detected. The entity class management framework 102 is configured to, upon receiving a notification from the change listening module regarding a database table, retrieve the changed table structure metadata from the metadata storage 105, and call the bytecode generation engine 103 to dynamically generate the bytecode of the first version entity class of the database table based on the table structure metadata, and load the bytecode of the first version entity class through the custom class loader 104. Among them, the entity class management framework, as an intermediate layer between the application and the ORM framework, is responsible for the entire lifecycle management of entity classes. Custom class loader 104 is configured to create a class loading space corresponding to the first version entity class, so that the first version entity class and the second version entity class associated with the database table can coexist at runtime. The second version entity class is the old version entity class that has been loaded in the database table. The entity class management framework 102 is also configured to notify the object-relational mapping framework 106 to update its metadata model after successfully loading the first version entity class of the database table, so that the object-relational mapping framework 106 can rebuild the internal mapping relationship to identify and use the first version entity class, and update the version information of the corresponding table structure of the database table in the metadata storage 105. The entity class management framework 102 is also configured to receive entity class retrieval requests from business systems for database tables, and, based on the version indication information corresponding to the entity class retrieval request, determine the target version entity class that matches the version indication information from multiple version entity classes associated with the database table, and return the target version entity class to the business system that initiated the request.

[0020] For example, such as Figure 2 As shown, assuming a new field "age" is added to the database table "user", and the table structure change triggers a dynamic update of the entity class, the system workflow is as follows: When the database (dba) or automated script performs a DDL operation, it initiates a DDL command (such as "alter tableuser add column 'age' int"). The change monitoring module detects the change in the "user" table structure by polling or listening to the binlog and notifies the entity class management framework. The entity class management framework marks old version entity classes as "obsolete" and requests the bytecode generation engine to generate a new version (v2) user entity class (i.e. the first version entity class) for the "user" table. The bytecode generation engine generates v2 class bytecode containing the age field and returns it to the entity class management framework; A custom class loader defines the v2 class in an independent class loading space, loads the v2 class, and coexists in isolation with the existing v1 class (i.e., the second version entity class). At this time, the old v1 version entity class can still be used by the old business logic. After the custom class loader returns the v2 version of the class object to the entity class management framework, the entity class management framework notifies the integrated ORM framework (such as Hibernate) that its metadata has changed, for example by triggering Hibernate's Metamodel refresh event or a similar mechanism, so that the ORM framework can rebuild its internal mapping relationship and identify new fields such as age, so that subsequent new query statements include the "age" field. Once the entity class management framework confirms the update, the change monitoring module will update the version information in the metadata storage to v2; In this way, for subsequent business requests from the business system, when requesting the "user" entity class, if the version indicator information indicates the latest version, a new v2 class object can be returned, so that the business system can use the v2 class to create a query statement and the ORM framework can successfully return a result containing the "age" field.

[0021] In this way, by monitoring changes in the database table structure, bytecode for new versions of entity classes is dynamically generated, and hot-swapping of classes is achieved using a custom class loader. Simultaneously, the ORM framework is notified to update its metadata model. By implementing runtime dynamic updates of entity classes, the application can adapt to database changes without interrupting service, improving system flexibility, maintainability, and high availability. This is particularly suitable for modern application scenarios involving agile development and continuous deployment.

[0022] The entity class dynamic management system provided in this application solves the technical problem of traditional ORM frameworks requiring application service restarts due to the static binding of entity classes to database table structures by introducing a collaborative architecture consisting of a change monitoring module, an entity class management framework, a bytecode generation engine, a custom class loader, metadata storage, and an object-relational mapping (ORM) framework. Specifically, the change monitoring module continuously monitors DDL changes to the database table structure and triggers an update process upon detecting a change, enabling the system to respond to database changes in real time. The bytecode generation engine dynamically generates bytecode for new version entity classes based on the latest table structure metadata obtained from the metadata storage. Combined with an independent class loading space created by the custom class loader, it achieves runtime coexistence of old and new version entity classes, thus avoiding the need to stop application services to update entity classes. The entity class management framework receives entity class retrieval requests from business systems and accurately routes the target entity class from multiple coexisting versions based on version indication information, ensuring seamless operation of business logic during the transition period of database table structure changes. Simultaneously, the framework notifies the ORM framework to update its metadata model, enabling it to rebuild its internal mapping relationships to identify new version entity classes, ensuring the accuracy of data persistence operations. Thus, this solution enables "hot updates" of entity classes in agile development and CI / CD environments with frequent database schema changes. Through a custom class loading mechanism, changes to the database table structure take effect without requiring a restart of the application, reducing service downtime, operational complexity and risk, and ultimately achieving high availability and continuity of application services. Furthermore, it automates the synchronization process between entity classes and the database, reducing manual intervention by development and operations personnel, lowering the risk of human error, and accelerating iteration cycles.

[0023] To facilitate understanding, the following provides a detailed introduction to each component of the entity-based dynamic management system.

[0024] According to an embodiment of this application, optionally, the bytecode generation engine can be specifically configured as follows: according to a predefined mapping rule, the table name in the table structure metadata is parsed into the name of the entity class, and the column information is parsed into the field definition of the entity class to obtain the mapping result, wherein the field definition includes the field name, field type and access modifier; based on the mapping result, the bytecode structure of the entity class is constructed through the bytecode operation framework.

[0025] The bytecode manipulation framework can be the Java bytecode manipulation framework ASM, the Javassist library, etc., and this application does not specifically limit it. ASM can be used to construct the class structure of entity classes by directly manipulating Java bytecode instructions, obtaining the bytecode of the first version of the entity class; or, based on the Javassist library, the bytecode of the first version of the entity class of the database table can be dynamically generated through high-level source code abstraction.

[0026] According to embodiments of this application, optionally, the system may further include a version registry for maintaining the mapping relationship between registered version identifiers and class definition information of database tables; a custom class loader configured to register the version identifier and class definition information of the first version entity class associated with the database table in the version registry after successfully loading the first version entity class; and an entity class management framework specifically configured to, upon receiving an entity class retrieval request, query the version registry to filter out the target version identifier that matches the version indication information from all registered version identifiers in the database table, and determine the class definition information corresponding to the target version identifier as the target version entity class.

[0027] Specifically, the version registry uses a hash table structure, where the key is the version identifier and the value is a reference to the class object of the corresponding entity class. Upon receiving a request, the entity class management framework extracts the version indicator information, queries all keys in the version registry, and filters out the target version identifier using string matching or a rule engine (such as regular expressions). For example, when the version indicator is v2, it directly matches the entry with the key user_v2.

[0028] As a concrete example, such as Figure 3 As shown, for a period of time after the system update process based on the table structure change event is completed, both v1 and v2 versions of the "user" class exist simultaneously in the system. In this way, the entity class management framework can accurately provide different versions of the class according to the business logic's requests. For example, when an older version of the business logic that has not yet been refreshed requests the "user" class, the framework uses a custom class loader to find and provide the v1 version of the "user" entity class, and returns a v1 class object, allowing the older business logic to use the v1 class object to process data (at this time, there is no 'age' field). When a newly started or refreshed business logic requests the "user" entity class, the framework defaults to obtaining the latest version of the entity class. In this case, it uses a custom class loader to find and provide the latest v2 version, and returns a v2 class object, allowing the newer business logic to use the v2 class object to process data (at this time, it includes the 'age' field).

[0029] In this embodiment, the version registry provides centralized version control capabilities by maintaining the mapping relationship between version identifiers and class definition information. This enables the system to accurately track the entity class version corresponding to each database table structure change, ensuring the queryability and manageability of version information. Whether a specific version number is required or a certain version constraint (such as the latest stable version) needs to be met, the system can quickly and accurately locate the target by querying the version registry. This enhances the system's flexibility and determinism in dealing with different business scenarios, such as canary releases, version rollbacks, and multi-version parallel testing, making the dynamic loading behavior of entity classes more predictable and reliable.

[0030] Optionally, this application may maintain an associated version registry for each database table to store the mapping relationship between the registered version identifiers and class definition information of the database table; or, the mapping relationship between the registered version identifiers and class definition information of multiple database tables may be stored in the same version registry, and this application does not make any specific limitation on this.

[0031] According to an embodiment of this application, optionally, the entity class management framework is specifically configured as follows: when the version indication information is a specified version number, the version identifier that matches the specified version number among all registered version identifiers in the database table is determined as the target version identifier; when the version indication information is a version constraint expression of the database table, at least one candidate version identifier that satisfies the constraint condition corresponding to the version constraint expression is selected from all registered version identifiers in the database table, and a target candidate version identifier is selected from the at least one candidate version identifier as the target version identifier according to predefined rules; when the version indication information is the context information of the source business logic module of the entity class acquisition request, the context information is parsed to obtain the state feature information, and the version identifier that matches the state feature information among all registered version identifiers in the database table is determined as the target version identifier, and the state feature information is used to characterize the state of the source business logic module.

[0032] Specifically, version constraint expressions can be conditional expressions conforming to semantic versioning specifications, such as ^2.0.0, which means compatible with all versions greater than 2. State characteristic information can refer to state identifier fields extracted from the request context, such as X-Module-State: legacy in the HTTP request header, which indicates that the business logic module is in an unrefreshed state.

[0033] This application can execute different matching strategies based on the type of version indication information: Specify version number: Directly compare the version identifier string, such as requesting that the version number v2 exactly matches user_v2 in the registry.

[0034] Version constraint expressions: Use version comparison libraries such as SemVer to filter the candidate set that meets the conditions from all version identifiers. For example, the expression ">=1.0.0,<3.0.0" matches v1.0.0 and v2.1.0. Sort by version number in descending order and take the highest version as the target. For example, v2.1.0 is preferred over v1.0.0 in the candidate set.

[0035] Context information: Parse the request context, such as the module_state field in the thread-local variable. If the value is legacy, the module is determined to be in an unrefreshed state. Based on the state matching rules, such as the unrefreshed state corresponding to the previous version of the latest version, determine the target version identifier.

[0036] In this embodiment, a flexible multi-version routing strategy is supported, covering major application scenarios ranging from precise specification and conditional constraints to context-awareness. Specifically, when the version indication information is an explicit version number, the system can provide precise matching to meet strict requirements for a specific version; when it is a version constraint expression, the system can perform flexible version comparison and filtering to meet complex strategies such as "greater than a certain version" or "latest stable version," adapting to scenarios such as canary releases; when it is context information, the system implements state-aware intelligent version selection, enabling version decisions to adapt to the operating state of business modules. Thus, the multi-dimensional selection mechanism enhances the system's adaptability to complex deployments and runtime environments.

[0037] Furthermore, by associating version selection logic with specific business contexts (such as module status), the system can more intelligently decide which version of the entity class to load. For example, for newly started modules, the latest version of the entity class can be automatically assigned to take advantage of new features; for modules that are already running stably and are state-sensitive, a relatively stable or compatible older version may be matched to them. This isolation capability ensures that data processing between different modules will not interfere with each other during the change transition period, thus achieving dynamic updates while taking into account the stability and continuity of business, thereby improving system flexibility and business adaptability, and reducing the cost of business code modification.

[0038] According to an embodiment of this application, optionally, when the version indication information is the context information of the source business logic module of the entity class acquisition request, the entity class management framework is specifically configured as follows: when the status feature information is used to characterize that the source business logic module is in a newly started state or a refreshed state, the latest registered version identifier among all registered version identifiers in the database table is determined as the target version identifier that matches the status feature information; when the status feature information is used to characterize that the source business logic module is in a non-refreshed state or a state compatible with an old version, from all registered version identifiers in the database table, the version identifier whose registration time is closest to the latest registered version identifier is selected as the target version identifier that matches the status feature information, or, the currently loaded entity class version of the source business logic module is queried, and the version identifier of that entity class version is determined as the target version identifier.

[0039] Specifically, in the newly started / refreshed state, the version identifier with the largest registration timestamp in the registry is directly obtained; in the unrefreshed / compatible with old versions state, the time difference between the registration time of all version identifiers and the latest version can be calculated, and the version with the smallest difference is selected. For example, if the registration timestamp of v3 is T3 and that of v2 is T2, then if |T3-T2| is the smallest, then v2 is selected; or, the version of the entity class that has been loaded can be obtained from the runtime context of the business module, for example, by obtaining the version suffix in the class name through Java's getClass() method, thereby determining the currently loaded entity class version.

[0040] In this embodiment, the latest version is assigned to newly started or refreshed modules to ensure that new functions take effect promptly. For modules that have not been refreshed or require compatibility with older versions, the nearest version or the currently loaded version is used. This avoids runtime compatibility issues caused by sudden jumps in entity class version updates, ensuring the stable operation of critical business processes and demonstrating the system's intelligent fault tolerance and compatibility design. By matching the most suitable entity class version to modules in different states, the risk of runtime errors or service interruptions due to version incompatibility is reduced. Simultaneously, querying and reusing the currently loaded entity class version of the module avoids unnecessary class reloading and initialization overhead, saving system resources. While ensuring functional correctness, this also improves system performance and resource utilization.

[0041] According to an embodiment of this application, optionally, the monitoring module is configured to monitor data definition language operations on the database table structure in the following ways: periodically polling the system metadata table of the database to detect changes in data definition language operations; or parsing the binary log of the database to capture data definition language operation events from the binary log.

[0042] Specifically, in polling mode, a timer can be started to periodically execute SQL query statements. By comparing the differences between the current and previous query results, such as changes in the UPDATE_TIME field, it can be determined whether a table structure change has occurred. In event-driven mode, binary logs can be obtained in real time through the database's log subscription interface, such as MySQL's Binlog Stream. DDL events can be extracted using a parsing library, and change events of the target table can be filtered out.

[0043] In this embodiment, through polling or event-driven mechanisms, the system can capture database table structure changes in real time or near real time, ensuring the timeliness and accuracy of change monitoring. The system can select the most suitable monitoring scheme based on the specific database type, performance requirements, and technology stack. For example, in scenarios with extremely high real-time requirements, parsing the Binlog can be prioritized; while when resources are limited or the database version is not supported, polling can be used as an alternative. This flexibility enhances the applicability of the solution in different technical environments, thereby improving the system's adaptability and efficiency.

[0044] According to an embodiment of this application, optionally, the entity class management framework is further configured during system initialization to: in response to the startup of the business system or the first receipt of a request to obtain an entity class for a database table, query the latest version of the metadata corresponding to the database table from the metadata storage; check whether the version entity class corresponding to the latest version metadata has been loaded through a custom class loader; if not loaded, call the bytecode generation engine to dynamically generate the corresponding version of the entity class bytecode based on the latest version metadata, and load and cache the latest version entity class through the custom class loader; if loaded, directly return the cached latest version entity class.

[0045] Specifically, entity class loading is triggered only upon system startup or the first request, rather than preloading all versions. The latest version of metadata can be the table structure metadata with the highest version number in the metadata store. The following check and loading process is triggered when the system starts scanning all table metadata or when business code is called for the first time: The system queries the metadata store for the table with the highest version number; a custom class loader checks if a reference to that version class already exists in the memory cache; if not loaded, the bytecode generation engine dynamically generates the class and caches it; if loaded, the cached reference is returned directly.

[0046] As a concrete example, such as Figure 4 As shown, when a business system starts up or needs to access an entity, for example, when the business code calls the getEntityClass("user") method, the business system sends a request to the entity class management framework to obtain the entity class corresponding to the specified database table (such as the "user" table); In response to the request, the entity class management framework queries the metadata store to obtain the latest stable version of the metadata for the "user" table (e.g., version v2). The metadata store returns the latest version of the metadata (v2) to the entity class management framework. Based on the obtained v2 version metadata, the entity class management framework checks whether the v2 version of the entity class has been cached locally. If it has been cached, it directly returns the cached class object to the business system. If the entity class has not been loaded or needs to be updated, it sends a request to the custom class loader to load or find the class object corresponding to the v2 version. After receiving a request, the custom class loader checks the version information of the classes it has already loaded. If a class is already loaded, it returns it directly from the cache to the entity class management framework, ensuring high performance. If a class is not loaded, the class generation process is triggered: the custom class loader notifies the entity class management framework that a v2 version class needs to be generated; the entity class management framework provides the custom class loader with v2 version metadata; the custom class loader then calls a bytecode generation engine (such as the ASM framework) to dynamically generate v2 version bytecode based on the v2 version metadata and defines the bytecode as a class object; after generation, the custom class loader caches the v2 class object and returns it to the entity class management framework.

[0047] The entity class management framework returns the final obtained v2 class object to the business system. The business system uses the obtained class object to perform ORM operations, such as executing session.createQuery(...). The ORM framework processes data operations based on internal mapping relationships and returns the operation results to the business system.

[0048] In this embodiment, by stipulating that the latest metadata is actively queried and the latest version of the entity class is checked and generated / loaded upon system startup or the first request, the consistency between the internal entity classes and the database table structure of the application in the initial stage is ensured. This improves the latency or concurrency issues that may be caused by loading only upon the first access during business operation, ensuring that the system is in a known correct state from startup and improving the initial availability of the system. Through the "check-generate / load-cach" process, combined with a caching mechanism, once the latest version of the entity class is loaded, subsequent requests for the same version can be quickly retrieved directly from the cache, avoiding the overhead of repeated metadata queries and bytecode generation, reducing the latency of entity class retrieval, and improving the system's response efficiency when handling high-frequency requests.

[0049] According to an embodiment of this application, optionally, the internal mapping relationship is the mapping relationship between entity classes and database table structures. When the entity class management framework notifies the object-relational mapping framework to update its metadata model, the specific configuration is as follows: triggering the metadata refresh event defined by the object-relational mapping framework so that the object-relational mapping framework rebuilds the internal mapping relationship asynchronously; or, calling the metamodel reconstruction application interface provided by the object-relational mapping framework so that the object-relational mapping framework rebuilds the internal mapping relationship synchronously.

[0050] Metadata refresh events refer to internal events provided by the ORM framework, such as Metamodel RefreshEvent, which asynchronously rebuilds the mapping cache after being triggered. The metamodel rebuild application interface can be a synchronous API exposed by the ORM framework, such as Hibernate's MetamodelImpl.rebuild().

[0051] Specifically, asynchronous methods can include: the entity class management framework publishing events to the ORM framework's event listener, and the ORM rescanning entity class annotations and updating the mapping cache in a background thread without blocking the current request; synchronous methods involve directly calling the ORM's API, blocking the current thread until the mapping is rebuilt, such as ensuring that the newly added field age is recognized before returning a response.

[0052] In this embodiment of the application, by triggering the update of the ORM framework metadata model, it is ensured that the entity class structure (such as fields and types) perceived by the ORM framework is synchronized with the actual table structure of the database and the newly loaded new version of the entity class. This improves the failure of data operations (such as adding, deleting, modifying, and querying) or data corruption caused by inconsistent mapping, and ensures the correctness and reliability of the data access layer.

[0053] Furthermore, it provides two methods for notifying the ORM framework to update its internal metadata model: asynchronous event triggering and synchronous API calls. The asynchronous method helps decouple and avoids blocking the main process, making it suitable for scenarios where real-time requirements are not extremely high. The synchronous method ensures that subsequent operations are performed only after the metamodel is rebuilt, guaranteeing strong consistency. These two strategies allow the system to choose and switch between them based on the different consistency and performance requirements of specific business needs, enhancing the flexibility of system integration.

[0054] According to an embodiment of this application, optionally, it also includes a management interface module, configured to: receive a manual refresh instruction initiated by the administrator through a graphical management interface or an application programming interface (API), and forward the manual refresh instruction to the entity class management framework; the entity class management framework is further configured to, in response to the manual refresh instruction, re-execute the complete process of obtaining table structure metadata from the metadata storage, generating bytecode, loading entity classes, notifying the object relational mapping framework, and updating version information.

[0055] The management interface module refers to the component that provides an external operation entry point, such as the REST API endpoint POST / api / refresh. Manual refresh commands refer to forced update commands triggered by the administrator through the interface or API, such as carrying the table name parameter {"table": "user"}. The management interface module receives requests via HTTP, parses the parameters, verifies permissions, and forwards the command to the entity class management framework. The framework then re-executes the following complete process: retrieves the latest table structure metadata from the metadata store; generates and registers the new version of the entity class; notifies the ORM framework to update the metadata model; and updates the version information in the metadata store.

[0056] As a concrete example, combined with Figure 5 This document details the complete process by which administrators or developers manually trigger entity class hot refresh via the management interface or API. It demonstrates the controllable management intervention methods provided by the system beyond the automatic monitoring mechanism. Administrators or developers can click the "Refresh Entity Classes" button on the management interface (such as a web console) or call a specific application programming interface (API) via a command-line tool, such as sending a manual refresh command to the endpoint POST / api / entities / refresh / user. The management interface / API receives this command and forwards it to the entity class management framework. In response to this instruction, the entity class management framework initiates a hot update process: First, the entity class management framework rereads the latest metadata of the target database table (e.g., the "user" table) from the metadata store; then, the entity class management framework calls the bytecode generation engine and requests it to generate new entity class bytecode based on the newly acquired metadata; after the bytecode generation engine completes the generation, it returns the new bytecode to the entity class management framework; the entity class management framework instructs the custom class loader to load the newly generated bytecode; after receiving the bytecode, the custom class loader defines it as a new Class object. During this process, the custom class loader manages the lifecycle of the class, such as marking previously loaded older versions of the class as pending unloading; after successful loading, the custom class loader returns the new class object to the entity class management framework. After successfully obtaining the new version of the entity class, the entity class management framework immediately notifies the ORM framework, informing it that its metadata model has changed. Upon receiving the update notification, the ORM framework performs a synchronous update of its internal metadata model, such as rebuilding the mapping relationship between entity classes and database tables, to ensure that subsequent data operations are based on the new table structure. After the update is completed, the ORM framework confirms to the entity class management framework that the update operation is complete. After receiving confirmation from the ORM framework, the entity class management framework generates a final message indicating a successful refresh and returns it to the administrator or developer via the management interface / API. The administrator or developer receives a success message "Entity class has been hot-updated" on the management interface or receives a successful response via API call.

[0057] In this way, a complete manual hot update process is completed, ensuring that the business system can immediately use entity classes that are fully synchronized with the latest database structure.

[0058] In this embodiment, a manual refresh command entry is provided through a graphical interface or API, giving system administrators the ability to proactively trigger a full-process refresh. This enhances the controllability and robustness of system operation and maintenance for scenarios such as planned maintenance, forced synchronization after emergency repairs, or manual intervention when the automated monitoring mechanism fails. Furthermore, the manual refresh command reduces the system's complete reliance on the automatic monitoring mechanism. In special circumstances where the automated process may experience delays, omissions, or anomalies, administrators can manually ensure eventual consistency, providing an alternative path and additional safeguards for system maintenance, thus enhancing the flexibility and fault tolerance of system operation and maintenance.

[0059] Figure 6 This is a flowchart illustrating an embodiment of the object-oriented relational mapping entity class dynamic management method provided in this application. The executing entity of this object-oriented relational mapping entity class dynamic management method can be the aforementioned object-oriented relational mapping entity class dynamic management system (hereinafter referred to as "the system").

[0060] The following example, using the system as the execution entity of the object-oriented relational mapping entity class dynamic management method, illustrates the object-oriented relational mapping entity class dynamic management method of this application. It should be noted that the above-mentioned execution entity and application scenario do not constitute a limitation on this application.

[0061] Step 610: The change listening module listens for Data Definition Language operations on the database table structure and notifies the entity class management framework when it detects a table structure change event. Step 620: When the entity class management framework receives a notification from the change listening module for the database table, it retrieves the changed table structure metadata from the metadata storage, and calls the bytecode generation engine to dynamically generate the bytecode of the first version entity class of the database table based on the table structure metadata, and loads the bytecode of the first version entity class through a custom class loader. Step 630: A custom class loader creates a class loading space corresponding to the first version entity class, so that the first version entity class and the second version entity class associated with the database table can coexist at runtime. The second version entity class is the old version entity class that has been loaded in the database table. Step 640: After successfully loading the first version of the entity class in the database table, the entity class management framework notifies the object-relational mapping framework to update its metadata model, so that the object-relational mapping framework can rebuild its internal mapping relationship to identify and use the first version of the entity class, and update the version information of the corresponding table structure in the metadata store. In step 650, the entity class management framework also receives entity class retrieval requests from business systems for database tables, and determines the target version entity class that matches the version indication information from multiple version entity classes associated with the database table based on the version indication information corresponding to the entity class retrieval request, and returns the target version entity class to the business system that initiated the request.

[0062] The entity class dynamic management method provided in this application continuously monitors DDL changes to the database table structure through a change monitoring module, triggering an update process upon detection of a change, enabling the system to respond to database changes in real time. The bytecode generation engine dynamically generates bytecode for new version entity classes based on the latest table structure metadata obtained from the metadata store. Combined with an independent class loading space created by a custom class loader, this achieves runtime coexistence of old and new version entity classes, thus avoiding the need to stop application services for updating entity classes. The entity class management framework receives entity class retrieval requests from business systems and accurately routes the target entity class from multiple coexisting versions based on version indication information, ensuring seamless operation of business logic during the transition period of database table structure changes. Simultaneously, the framework notifies the object-relational mapping framework to update its metadata model, enabling it to rebuild its internal mapping relationships to identify new version entity classes, ensuring the accuracy of data persistence operations. Thus, this solution enables "hot updates" of entity classes in agile development and CI / CD environments where database schemas change frequently. This is achieved through a custom class loading mechanism, allowing the application to take effect without restarting after database table structure changes. This reduces service downtime, operational complexity and risk, and ultimately achieves high availability and continuity of application services. Furthermore, it automates the synchronization process between entity classes and the database, reducing manual intervention by development and operations personnel, lowering the risk of human error, and accelerating iteration cycles.

[0063] The object-oriented relational mapping entity class dynamic management method provided in this application can achieve... Figures 2-5 The various processes implemented in the embodiments can achieve the same technical effects, and will not be described again here to avoid repetition.

[0064] Figure 7 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application.

[0065] like Figure 7As shown, the electronic device 700 includes a memory 701, a processor 702, and a computer program stored in the memory 701 and executable on the processor 702.

[0066] In one example, the processor 702 described above may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0067] Memory 701 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the object-oriented relational mapping entity class dynamic management method according to the embodiments of the first aspect of this application.

[0068] The processor 702 runs a computer program corresponding to the executable program code by reading the executable program code stored in the memory 701, in order to implement the object-oriented relational mapping entity class dynamic management method in the first aspect embodiment above.

[0069] In some examples, the electronic device 700 may also include a communication interface 703 and a bus 710. For example, Figure 7 As shown, the memory 701, processor 702, and communication interface 703 are connected through bus 710 and complete communication with each other.

[0070] The communication interface 703 is mainly used to enable communication between various modules, systems, units, and / or devices in the embodiments of this application. Input devices and / or output devices can also be connected through the communication interface 703.

[0071] Bus 710 includes hardware, software, or both, that couples components of electronic device 700 together. For example, and not limitingly, bus 710 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-E) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 710 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.

[0072] The electronic device provided in this application embodiment is capable of achieving Figures 2-5 The various processes implemented in the embodiments can achieve the same technical effects, and will not be described again here to avoid repetition.

[0073] Based on the object-oriented relational mapping entity class dynamic management method in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any step in the above method embodiments.

[0074] Based on the object-oriented relational mapping entity class dynamic management method in the above embodiments, this application embodiment can provide a computer program product for implementation. This (computer) program product is stored in a non-volatile storage medium, and when executed by at least one processor, it implements any step in the above method embodiments.

[0075] This application also provides a chip, which includes a processor and a communication interface. The communication interface and the processor are coupled. The processor is used to run programs or instructions to implement the various processes of the above method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0076] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0077] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0078] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0079] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or systems. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0080] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, systems (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing system to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing system, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0081] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A dynamic management system for entity classes using object-oriented relational mapping, characterized in that, include: Changes were made to the listening module, entity class management framework, bytecode generation engine, custom class loader, metadata storage, and object-relational mapping framework. The change monitoring module is configured to monitor data definition language operations on the database table structure and notify the entity class management framework when a table structure change event is detected. The entity class management framework is configured to, upon receiving a notification from the change monitoring module regarding a database table, retrieve the changed table structure metadata from the metadata storage, and call the bytecode generation engine to dynamically generate the bytecode of the first version entity class of the database table based on the table structure metadata, and load the bytecode of the first version entity class through the custom class loader. The custom class loader is configured to create a class loading space corresponding to the first version entity class, so that the first version entity class and the second version entity class associated with the database table can coexist at runtime, and the second version entity class is the old version entity class that has been loaded in the database table; The entity class management framework is further configured to, after successfully loading the first version entity class of the database table, notify the object-relational mapping framework to update its metadata model, so that the object-relational mapping framework can rebuild the internal mapping relationship to identify and use the first version entity class, and update the version information of the corresponding table structure of the database table in the metadata storage. The entity class management framework is further configured to receive entity class retrieval requests from business systems for database tables, and, based on the version indication information corresponding to the entity class retrieval request, determine the target version entity class that matches the version indication information from multiple version entity classes associated with the database table, and return the target version entity class to the business system that initiated the request.

2. The system according to claim 1, characterized in that, The system also includes a version registry, which is used to maintain the mapping relationship between registered version identifiers and class definition information in the database tables; The custom class loader is further configured to register the version identifier and class definition information of the first version entity class associated with the database table in the version registry after successfully loading the first version entity class; The entity class management framework is specifically configured to, upon receiving an entity class retrieval request, query the version registry, filter out the target version identifier that matches the version indication information from all registered version identifiers in the database table, and determine the class definition information corresponding to the target version identifier as the target version entity class.

3. The system according to claim 2, characterized in that, The specific configuration of the entity class management framework is as follows: When the version indication information is a specified version number, the version identifier that matches the specified version number among all registered version identifiers in the database table is determined as the target version identifier; When the version indication information is a version constraint expression of a database table, at least one candidate version identifier that satisfies the constraint conditions corresponding to the version constraint expression is selected from all registered version identifiers in the database table, and a target candidate version identifier is selected from at least one candidate version identifier as the target version identifier according to predefined rules. When the version indication information is the context information of the source business logic module of the entity class acquisition request, the context information is parsed to obtain the status feature information, and the version identifier that matches the status feature information among all registered version identifiers in the database table is determined as the target version identifier. The status feature information is used to characterize the status of the source business logic module.

4. The system according to claim 3, characterized in that, When the version indication information is the context information of the source business logic module of the entity class acquisition request, the entity class management framework is specifically configured as follows: When the status feature information is used to characterize whether the source business logic module is in a newly started state or a refreshed state, the latest registered version identifier among all registered version identifiers in the database table is determined as the target version identifier that matches the status feature information. When the status feature information is used to characterize the source business logic module as being in an unrefreshed state or a state compatible with an old version, the version identifier closest to the registration time of the latest registered version identifier is selected from all registered version identifiers in the database table as the target version identifier that matches the status feature information. Alternatively, the version of the entity class currently loaded by the source business logic module is queried, and the version identifier of that entity class version is determined as the target version identifier.

5. The system according to claim 1, characterized in that, The change monitoring module is specifically configured to monitor Data Definition Language (DDL) operations on the database table structure in the following ways: Periodically poll the database's system metadata tables to detect changes in data definition language operations; or, Parse the database's binary logs and capture Data Definition Language (DDL) operation events from the binary logs.

6. The system according to claim 1, characterized in that, The entity class management framework is also configured as follows during system initialization: In response to the startup of the business system or the first receipt of a request to obtain the entity class of the database table, the latest version of the metadata corresponding to the database table is queried from the metadata storage; The custom class loader is used to check whether the version entity class corresponding to the latest version of the metadata has been loaded. If not loaded, the bytecode generation engine is invoked to dynamically generate the corresponding version of entity class bytecode based on the latest version of metadata, and the latest version of entity class is generated by loading and caching it through the custom class loader; If it is already loaded, the latest cached version of the entity class will be returned directly.

7. The system according to claim 1, characterized in that, The internal mapping relationship is the mapping relationship between entity classes and database table structures. When the entity class management framework notifies the object-relational mapping framework to update its metadata model, the specific configuration is as follows: Trigger the metadata refresh event defined by the object-relational mapping framework so that the object-relational mapping framework can rebuild the internal mapping relationship asynchronously; or, The application programming interface for rebuilding the metamodel provided by the object-relational mapping framework is invoked, enabling the object-relational mapping framework to synchronously reconstruct its internal mapping relationships.

8. The system according to claim 1, characterized in that, It also includes a management interface module, configured as follows: The system receives manual refresh commands initiated by the administrator through a graphical management interface or application programming interface, and forwards the manual refresh commands to the entity class management framework. The entity class management framework is also configured to, in response to the manual refresh command, re-execute the complete process of obtaining table structure metadata from the metadata storage, generating bytecode, loading entity classes, notifying the object relationship mapping framework, and updating version information.

9. A method for dynamic management of entity classes using object-oriented relational mapping, characterized in that, include: The change monitoring module listens for Data Definition Language operations on the database table structure and notifies the entity class management framework when it detects a table structure change event. When the entity class management framework receives a notification from the change listening module regarding a database table, it retrieves the changed table structure metadata from the metadata storage, and calls the bytecode generation engine to dynamically generate the bytecode of the first version entity class of the database table based on the table structure metadata, and loads the bytecode of the first version entity class through a custom class loader. The custom class loader creates a class loading space corresponding to the first version entity class, so that the first version entity class and the second version entity class associated with the database table can coexist at runtime. The second version entity class is the old version entity class that has been loaded in the database table. After successfully loading the first version of the entity class in the database table, the entity class management framework notifies the object-relational mapping framework to update its metadata model, so that the object-relational mapping framework can rebuild its internal mapping relationship to identify and use the first version of the entity class, and update the version information of the corresponding table structure of the database table in the metadata storage. The entity class management framework receives an entity class retrieval request from a business system for a database table, and determines the target version entity class that matches the version indication information from multiple version entity classes associated with the database table based on the version indication information corresponding to the entity class retrieval request, and returns the target version entity class to the business system that initiated the request.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the method as described in claim 9.

Images