Database entity refreshing method and system and storage medium

Abstract

The invention provides a database entity refreshing method and system and a storage medium. The method comprises the following steps: monitoring table structure change of a database to obtain structure metadata of each data table and a corresponding last change timestamp; each last change timestamp is compared with a corresponding refreshing timestamp of a local cache, and a target data table with a changed structure is judged based on comparison; triggering a dynamic code generation process for the target data table in response to the target data table; dynamically generating an entity class code and a data access layer component code corresponding to the target data table based on the target structure metadata of the target data table and a predefined code generation template; loading the entity class code and the data access layer component code into an application running environment through a dynamic class loading mechanism to replace or register the corresponding class definition; and updating the refresh timestamp information corresponding to the target data table in the local cache after dynamic class loading is completed. The database can be efficiently maintained at low cost.

Description

Technical Field

[0001] This application relates to the field of database management and application development technology, and in particular to a database entity refresh method, system and storage medium. Background Technology

[0002] In database-driven application development, changes to the database table structure are a common scenario as business requirements evolve. In traditional development models, when the database table structure changes, developers need to manually modify the corresponding entity classes, data access layers, and related business logic code, then recompile, repackage, and restart the application to achieve consistency between the code and the database structure. This approach is not only inefficient and prone to human error, but it can also lead to application service outages and impact system availability.

[0003] To mitigate the impact of restarts, several improvements have emerged in existing technologies, such as using hot deployment tools to update parts of the code at runtime, or leveraging reflection to dynamically handle field changes. However, hot deployment tools typically require additional payment and are complex to configure, making them difficult to apply across various environments. While reflection-based methods offer some flexibility, their performance is poor, and they lack compile-time type safety checks, making them prone to runtime exceptions. Furthermore, none of the above methods can automatically generate complete data access and business logic layer code, still requiring manual intervention and failing to fundamentally solve the problems of low development efficiency and high maintenance costs. Summary of the Invention

[0004] To enable efficient and low-cost database maintenance, this application provides a database entity refresh method, system, and medium.

[0005] Firstly, a database entity refresh method is provided, the method comprising:

[0006] Monitor changes to the database table structure to obtain the structural metadata of each table and the corresponding last change timestamp;

[0007] Each of the last change timestamps is compared with the corresponding refresh timestamp in the local cache, and the target data table whose structure has changed is determined based on the comparison.

[0008] In response to the target data table, a dynamic code generation process for the target data table is triggered;

[0009] Based on the target structure metadata of the target data table and the predefined code generation template, the entity class code and data access layer component code corresponding to the target data table are dynamically generated.

[0010] The entity class code and data access layer component code are loaded into the application runtime environment through a dynamic class loading mechanism to replace or register the corresponding class definitions.

[0011] After the dynamic class loading is completed, update the refresh timestamp information in the local cache corresponding to the target data table.

[0012] In some embodiments, the predefined code generation template includes a predefined entity class code template and a predefined data access layer component template. The dynamic generation of entity class code and data access layer component code corresponding to the target data table based on the target structure metadata of the target data table and the predefined code generation template includes:

[0013] Parse the target structure metadata to obtain the table name, field name, field type, and constraint information of the target data table;

[0014] The table name, field name, field type, and constraint information are combined with a predefined entity class code template to generate entity class code that conforms to the JavaBean specification and includes corresponding field definitions and annotations;

[0015] Based on the entity class code and the predefined data access layer component template, data access layer component code is generated that integrates with the general basic mapper interface and corresponds to the target data table. The data access layer component code includes generic parameter declarations based on the entity class code.

[0016] In some embodiments, loading the entity class code and data access layer component code into the application runtime environment via a dynamic class loading mechanism to replace or register the corresponding class definitions includes:

[0017] The entity class code and data access layer component code are compiled and loaded using the Groovy class loader to generate the corresponding first type of object;

[0018] Register the first type of object to the Spring application context to generate the corresponding Bean definition;

[0019] Determine whether a second type of object corresponding to the target data table exists in the Spring application context, wherein the second type of object is a class object that was registered before the dynamic code generation process was triggered;

[0020] If they exist, the first type of object is replaced with the second type of object through a version control mechanism, and the Bean definition in the Spring application context is updated to maintain the dependency injection relationship;

[0021] If it does not exist, register and inject the first type of object as a new Bean definition.

[0022] In some embodiments, updating the refresh timestamp information corresponding to the target data table in the local cache after the dynamic class loading is completed includes:

[0023] Obtain the identification information of the target data table, and query the database system table based on the identification information to obtain the latest change timestamp of the target data table;

[0024] The latest change timestamp is used to replace the original refresh timestamp record corresponding to the target data table in the local cache through an atomic write operation.

[0025] In some embodiments, monitoring changes to the table structure of the database to obtain the structural metadata of each table and its corresponding last change timestamp includes:

[0026] Periodically query the database system tables to obtain a set of version information containing the last modification timestamp of each data table;

[0027] The version information set is compared with the version information cached in the previous period to filter out the data table whose last modification timestamp has been updated as the table to be checked;

[0028] Obtain the current complete structural metadata of the table to be checked, and compare it with the pre-stored historical structural metadata to identify the type of structural change;

[0029] When the structural change type is identified, the last modification timestamp is used as the valid last change timestamp.

[0030] In some embodiments, the method further includes:

[0031] Read a set of system configuration parameters, including database connection parameter group, code generation parameter group, cache management parameter group, and performance tuning parameter group, from a predefined configuration source;

[0032] Initialize the database connection manager instance based on the database connection parameter group;

[0033] The instantiation parameters of the predefined code generation template are initialized based on the code generation parameter group;

[0034] The storage and invalidation policies of the local cache are initialized based on the cache management parameter group.

[0035] Initialize the thread pool and batch processing parameters involved in the monitoring, dynamic code generation, and dynamic class loading processes based on the performance tuning parameter group;

[0036] Apply the initialized manager instances and parameter configurations to the corresponding modules.

[0037] In some embodiments, replacing the second type of object with the first type of object through a version control mechanism includes:

[0038] Generate a new version identifier for the first type of object and retain historical version identifiers for the second type of object;

[0039] Based on the new version identifier and the historical version identifier, parallel Bean definition registration is established in the Spring application context, and newly received business requests are routed to the first type of object corresponding to the new version identifier for processing;

[0040] For existing business requests that have been received by the second type of object but have not yet been processed, they will continue to be processed by the second type of object until they are completed.

[0041] After confirming that all existing business requests have been processed and the first column objects are running stably, the corresponding Bean definition of the second type is removed from the Spring application context and its occupied memory resources are reclaimed.

[0042] In some embodiments, the method further includes:

[0043] Based on the entity class code and data access layer component code, the complete CRUD operation interface corresponding to the target data table is automatically assembled.

[0044] The automated assembly includes:

[0045] Parse the entity class code to obtain the entity class type, and unlock the data access layer component code to obtain the mapper type integrated from the general basic mapper interface;

[0046] Based on the entity class type and the mapper type, type binding is performed through the Java generic parameters declared in the data access layer component code to generate type-safe service layer component code, wherein the service layer component code encapsulates the calling logic of the predefined CRUD methods in the mapper type;

[0047] The service layer component code is loaded and registered into the Spring application context through the dynamic class loading mechanism to form a complete data access chain from the entity layer, mapping layer to the service layer.

[0048] Secondly, a database entity refresh system is provided, the system comprising: a monitoring module, a processing module, a response module, and a refresh module; wherein,

[0049] The monitoring module is used to monitor changes in the database table structure to obtain the structural metadata of each data table and the corresponding last change timestamp.

[0050] The processing module is used to compare each of the last change timestamps with the corresponding refresh timestamps in the local cache, and determine the target data table whose structure has changed based on the comparison.

[0051] The response module is used to trigger a dynamic code generation process for the target data table in response to the target data table;

[0052] The refresh module is used to dynamically generate entity class code and data access layer component code corresponding to the target data table based on the target structure metadata of the target data table and a predefined code generation template; load the entity class code and data access layer component code into the application runtime environment through a dynamic class loading mechanism to replace or register the corresponding class definitions; and update the refresh timestamp information corresponding to the target data table in the local cache after the dynamic class loading is completed.

[0053] Thirdly, a computer-readable storage medium is provided having a computer program stored thereon that can run on a processor, wherein when executed by the processor, the computer program implements a database entity refresh method as described in the first aspect.

[0054] By employing the above method, this application monitors changes in the database table structure to obtain the structural metadata of each table and its corresponding last change timestamp. Each last change timestamp is compared with the corresponding refresh timestamp in the local cache, and the target data table whose structure has changed is identified based on the comparison. In response to the target data table, a dynamic code generation process is triggered. Based on the target data table's structural metadata and a predefined code generation template, entity class code and data access layer component code corresponding to the target data table are dynamically generated. The entity class code and data access layer component code are loaded into the application runtime environment through a dynamic class loading mechanism to replace or register the corresponding class definitions. After dynamic class loading is completed, the refresh timestamp information corresponding to the target data table in the local cache is updated. This allows for efficient and low-cost database maintenance. Attached Figure Description

[0055] Figure 1 This is a flowchart of a database entity refresh method provided in this application.

[0056] Figure 2 This is a schematic diagram of the system architecture for the database entity refresh operation provided in this application.

[0057] Figure 3 This is a flowchart illustrating a database entity refresh method provided in this application.

[0058] Figure 4 This is a schematic diagram of a database entity refresh system connection provided in this application. Detailed Implementation

[0059] To better understand the purpose, technical solutions, and advantages of this application, it has been described and illustrated below with reference to the accompanying drawings and embodiments. However, those skilled in the art should understand that this application can be implemented without these details. It will be apparent to those skilled in the art that various modifications can be made to the embodiments disclosed in this application, and the general principles defined in this application can be applied to other embodiments and application scenarios without departing from the principles and scope of this application. Therefore, this application is not limited to the illustrated embodiments, but is consistent with the broadest scope claimed in this application.

[0060] The embodiments of this application will now be described in further detail with reference to the accompanying drawings. Figure 1 This is a flowchart of a database entity refresh method provided in this application. For example... Figure 1 As shown, a database entity refresh method includes the following steps:

[0061] Step S100: Monitor changes in the database table structure to obtain the structural metadata of each data table and the corresponding last change timestamp.

[0062] This application describes the process from the refresh perspective. Before monitoring changes to the database table structure, initialization is required. This involves reading a set of system configuration parameters from a predefined configuration source, including database connection parameter groups, code generation parameter groups, cache management parameter groups, and performance tuning parameter groups. The database connection manager instance is initialized based on the database connection parameter group; the instantiation parameters of the predefined code generation template are initialized based on the code generation parameter group; the storage and invalidation policies of the local cache are initialized based on the cache management parameter group; and the thread pool and batch processing parameters involved in monitoring, dynamic code generation, and dynamic class loading are initialized based on the performance tuning parameter group. The initialized manager instances and parameter configurations are then applied to the corresponding modules.

[0063] Specifically, during the startup phase, the system first reads a set of configuration parameters from predefined configuration sources such as YAML configuration files, environment variables, or configuration centers. This set includes database connection parameter groups, code generation parameter groups, cache management parameter groups, and performance tuning parameter groups.

[0064] Then, based on the data connection parameter group, a database connection manager instance is initialized. This instance uses connection pooling technology to manage multiple database sessions, supports automatic reconnection in case of failure and connection leak detection, and ensures that the monitoring function can stably obtain table structure metadata. Based on the code generation parameter group, code generation templates such as Groovy script templates are parsed and preloaded, and their instantiation parameters, such as entity class naming rules and field mapping strategies, are injected into the dynamic code generation engine. This eliminates the need for repeated template parsing during subsequent code generation, improving generation efficiency. Based on the cache management parameter group, local cache storage strategies such as LRL or TTL and invalidation strategies such as timed refresh or event-driven refresh are initialized, and a multi-level cache structure is established to maintain the table structure version and timestamp mapping in memory, avoiding frequent access to database system tables. Based on the performance tuning parameter group, the monitoring thread pool, dynamic code generation task queue, and dynamic class loading thread group are initialized, and batch processing parameters, such as the maximum number of tables processed per batch, are set to balance resource consumption and response speed in high-concurrency scenarios.

[0065] Finally, the initialized manager instances and parameter configurations are dynamically injected into the corresponding functional modules. For example, the database connection manager is bound to the monitoring module, and the cache manager is bound to the change detector, forming a pluggable and configurable runtime architecture. This ensures that the subsequent entity refresh process has high maintainability and elastic scalability. This decouples configuration from code, supports differentiated deployments in different environments, and significantly reduces latency in the monitoring and code generation stages through pre-loading templates and connection pooling management. Fine-tuning of multi-level caching and thread pools ensures stable performance even in scenarios with frequent table structure changes, reducing response jitter caused by resource contention. This provides reliable infrastructure support for subsequent real-time detection, dynamic generation, and hot reloading, and overall facilitates zero-restart, high-efficiency, and type-safe database entity refresh capabilities.

[0066] After completing the above initialization configuration, the continuous monitoring phase begins to detect changes in the database table structure in real time. Monitoring changes to the database table structure to obtain the structural metadata of each table and its corresponding last change timestamp includes the following steps:

[0067] Step S101: Periodically query the database system tables to obtain a set of version information containing the last modification timestamp of each data table.

[0068] Step S102: Compare the version information set with the version information cached in the previous period to filter out the data table whose last modification timestamp has been updated as the table to be checked.

[0069] Step S103: Obtain the current complete structural metadata of the table to be checked, and compare it with the pre-stored historical structural metadata to identify the type of structural change.

[0070] Step S104: When a structural change type is identified, the last modification timestamp is used as the valid last change timestamp.

[0071] Specifically, the system first initiates a query to the database's system tables using the initialized database connection manager, according to the monitoring period set in the performance tuning parameter group. This query does not perform a full scan of all business tables; instead, it focuses on the last modified timestamps recorded in the system tables, efficiently collecting version snapshots of all tables in the current database. This forms a set of version information containing table identifier-last modified timestamp key-value pairs. This reduces the performance overhead of directly parsing the large business table structure and provides a data foundation for quickly identifying potential changes.

[0072] The version information set obtained from this round of queries is then compared with the version information from the previous monitoring period stored in the local cache. The comparison process employs an efficient hash comparison algorithm to quickly identify which data tables have had their last modified timestamps updated—that is, the timestamps in the cache are earlier than those in the database. These tables with changed timestamps are marked as tables to be checked. This implements the first layer of coarse-grained filtering, performing further in-depth analysis only on tables with changed timestamps, significantly reducing unnecessary metadata retrieval and comparison calculations to improve monitoring efficiency.

[0073] Next, for each table awaiting review, its detailed structural metadata is queried through the database connection manager, including the table name, names of all fields, data types, lengths, nullability, default values, primary keys, indexes, and constraint information. Then, the obtained current complete structural metadata is compared with the historical structural metadata of the table pre-stored in the cache management module. The comparison algorithm can accurately identify specific structural change types, such as adding fields, deleting fields, modifying field data types, modifying field lengths, adding or deleting constraints, etc. This transforms simple timestamp changes into specific, understandable table structure change semantics, providing precise input for subsequent targeted code regeneration.

[0074] Finally, only when it is confirmed in step S103 that the table to be checked has indeed undergone a substantial structural change, will the last modification timestamp obtained in step S101 be confirmed as a valid last change timestamp. If the timestamp is updated but no anomalies are found in the structural comparison, the timestamp change is ignored and subsequent processes are not triggered. This ensures the accuracy of change detection, reduces false triggers caused by non-structural database change operations, and guarantees that resource-intensive code generation and hot reloading processes are only initiated when truly needed.

[0075] This two-tiered comparison strategy, employing periodic queries of system tables and timestamp comparisons combined with structural difference comparisons, minimizes the frequency and computational load of direct access to business metadata while ensuring a high detection rate, significantly reducing the potential impact of monitoring on database performance. Secondly, accurate change type identification allows for targeted code generation, such as generating code only for newly added fields, improving the efficiency of the refresh process. Finally, the mechanism of determining valid timestamps based on substantial changes effectively filters out noise interference, ensuring the stability and reliability of the entire automatic refresh process and laying a solid and accurate data foundation for achieving hot updates of database entities with zero restarts.

[0076] Step S200: Compare each last change timestamp with the corresponding refresh timestamp in the local cache, and determine the target data table whose structure has changed based on the comparison.

[0077] After completing real-time monitoring of database table structure changes and obtaining the latest change timestamps for each table, the system enters the structure change judgment phase. Specifically, refresh timestamps are first read in batches from the cache, that is, using the table identifier as the key, the refresh timestamps corresponding to each table are retrieved in batches from the multi-level cache structure. This cache stores the timestamps recorded after the last successful code generation and class loading, representing the table structure version currently recognized by the application. To improve access efficiency, a grouped batch query strategy is adopted, and a local copy of the cache is set to avoid frequent remote reads.

[0078] Then, timestamp comparison and change marking are performed. Specifically, for each data table, the last change timestamp obtained in step S100 is compared with the refresh timestamp extracted from the cache. The comparison process uses an atomic comparison-marking mechanism to ensure that the change status of the same data table is not repeatedly or missed under high concurrency access. If the last change timestamp is later than the refresh timestamp, the data table is determined to be the target data table, and its identifier is added to the refresh queue. If the two are the same or the change timestamp is earlier, the table is considered to have not undergone structural changes, and subsequent processes are not triggered. A threshold tolerance range can be set to avoid misjudgments caused by database clock synchronization deviations.

[0079] Next, change type association and priority scheduling are performed. For tables marked as target data tables, the structural change types identified in step S103 are further associated, and appropriate refresh priorities are assigned to different types of changes. For example, changes involving structural expansion, such as adding fields or modifying field types, are given higher priority to ensure rapid synchronization to the application layer. Changes that do not affect the entity class structure, such as updating comments or adjusting indexes, can be assigned lower priority or delayed. The refresh queue is then sorted according to priority to ensure timely responses to critical changes.

[0080] Finally, exception handling and status write-back are performed. During the comparison process, if a table is found to have no corresponding refresh timestamp in the cache, it is considered to be loaded for the first time, directly marked as the target data table, and full code generation is triggered. All comparison results and marked statuses are updated in real time to the table status mapping table in the cache, and the judgment time, change type, and processing status are recorded, providing a tracking basis for monitoring and troubleshooting.

[0081] This cached timestamp comparison mechanism enables lightweight and highly accurate real-time detection of table structure changes. It only requires comparing timestamp values ​​in memory, eliminating the need for repeated database queries or parsing of the complete table structure, significantly reducing the resource consumption of the database and system during the detection process. Combined with priority scheduling and exception handling mechanisms, it ensures timely change identification while minimizing disturbances caused by invalid or low-frequency changes. This provides accurate and reliable target input for subsequent dynamic code generation and hot-swap functionality, ultimately supporting the system's zero-restart, high-performance, and perceptible entity refresh capabilities.

[0082] Step S300: In response to the target data table, a dynamic code generation process for the target data table is triggered.

[0083] After accurately identifying the target data table whose structure has changed and its change type, the process randomly enters the change response and task scheduling phase. Specifically, the change event is first encapsulated and a task is created. This involves encapsulating the identification information of each target data table identified in step S200, the detailed structural change type obtained from step S103, and the latest table structure metadata into a structured table structure change event object. This object serves as the input context for subsequent processes. Then, based on each change event object, the dynamic code generation engine creates a corresponding code generation task. This task specifies the generation target, the required input data, and task attributes. Next, task scheduling and resource coordination are performed. The created tasks are submitted to a dedicated thread pool task queue initialized by performance tuning parameter groups. The built-in scheduler sorts and schedules tasks according to their priority. The scheduler also checks the current load status of the dynamic code generation engine and coordinates with the class loading management module to ensure that high-priority tasks are only retrieved from the queue and distributed to the code generation engine for execution when the class loading environment is ready, thus avoiding resource contention and system state conflicts. Finally, the generation process is triggered and the context is passed. When the scheduler decides to execute a code generation task for a target data table, it formally triggers the dynamic code generation engine's workflow. This triggering action is not just a simple function call, but involves a complete context switch. The engine receives a task package containing the latest structure metadata, change history, and pre-loaded code generation template instances for the target data table. This ensures the generation process is stateful and goal-oriented, preparing all the necessary prerequisites for subsequent precise code generation based on templates and metadata. The entire triggering process is asynchronous and non-blocking; the monitoring and change detection threads can continue working after the task is submitted, decoupling the detection and generation stages. By encapsulating table structure change events into standardized tasks and introducing a priority-based intelligent scheduling and resource coordination mechanism, efficient and orderly triggering of the dynamic code generation process is achieved. Furthermore, by decoupling change detection and code generation and ensuring that the generation task carries a complete context, not only is the reliability and efficiency of the triggering stage improved, but a solid foundation is also laid for generating high-quality, targeted code subsequently.

[0084] Step S400: Dynamically generate entity class code and data access layer component code corresponding to the target data table based on the target structure metadata of the target data table and the predefined code generation template.

[0085] After successfully triggering the dynamic code generation task for the target data table, the dynamic code generation phase begins. The predefined code generation templates include predefined entity class code templates and predefined data access layer component templates. The dynamic generation of entity class code and data access layer component code corresponding to the target data table, based on the target data table's target structure metadata and the predefined code generation templates, includes the following steps:

[0086] Step S401: Parse the target structure metadata to obtain the table name, field name, field type, and constraint information of the target data table.

[0087] Step S402: Combine the table name, field name, field type, and constraints with the predefined entity class code template to generate entity class code that conforms to the JavaBean specification and includes the corresponding field definitions and annotations.

[0088] Step S403: Generate data access layer component code that is integrated from the general basic mapper interface and corresponds to the target data table based on the entity class code and the predefined data access layer component template. The data access layer component code includes generic parameter declarations based on the entity class code.

[0089] Specifically, after receiving the task package containing the latest structure and metadata of the target data table, the dynamic code generation engine first calls the metadata parser. This parser reads the metadata and precisely extracts key attributes such as table name, field names, data types, lengths, nullability, default values, primary key constraints, index information, and foreign key keys. The parsing process not only performs basic syntax analysis but also converts database-specific data types to their corresponding types in the target programming language, such as Java, according to configured mapping rules, preparing structured data objects for subsequent template population. The engine then injects these data objects into the pre-loaded entity class code template. This template is typically written in Groovy script and includes embedded variable placeholders and logical control statements. The engine checks all field information, creates corresponding private attributes for each field in the generated Java class, and generates standard getter and setter methods based on their data types, nullability, and other constraints. Simultaneously, the engine automatically adds necessary framework annotations based on the mapping rules. For example, for the MyBatis-Plus framework, it adds the `@TableName` annotation to the class and fills in the table name, adds the `@TableField` annotation to the fields and configures the mapping relationship, and adds the `@TableId` annotation to the primary key field and specifies the primary key strategy. This fully automated process ensures that the generated entity class code is not only syntactically correct but can also work directly with the specified ORM framework.

[0090] Finally, after the entity class code is completed, the engine randomly generates the corresponding Mapper interface code using a predefined data access layer component template. This template is designed to integrate from a general basic mapper interface. The engine fills the corresponding position in the template with the fully qualified name of the entity class generated in step S403 above as the generic parameter T. The generated Mapper interface thus possesses type-safe, generic CRUD operation method declarations for this specific entity type, eliminating the need for developers to manually write any SQL statements. The entire generation process is automated, from parsing metadata to generating directly compileable entity classes and Mapper interface code. This achieves precise and efficient synchronization between database table structure changes and application layer code. The dynamic generation mechanism based on template and metadata parsing ensures absolute consistency between the code and the database structure. The generated code conforms to specifications and inherits necessary framework annotations, making it ready to use out of the box and significantly improving development efficiency and code quality. Simultaneously, through generic parameter binding, compile-time type safety checks are implemented at the data access layer, effectively avoiding runtime exceptions caused by field type mismatches, thus improving stability and maintainability.

[0091] After dynamically generating and loading entity classes and data access layer components, to achieve a complete closed loop from the data layer to the business layer, the automatic state of the CRUD operation interface is further executed, providing directly callable, type-safe data services to the target data table. This involves automatically assembling the complete CRUD operation interface corresponding to the target data table based on the entity class code and data access layer component code. The automatic assembly includes: parsing the entity class code to obtain the entity class type, and unlocking the data access layer component code to obtain the mapper type integrated from the general basic mapper interface. Based on the entity class type and mapper type, type binding is performed using the Java generic parameters declared in the data access layer component code to generate type-safe service layer component code. This service layer component code encapsulates the calling logic for predefined CRUD methods in the mapper type. The service layer component code is then loaded and registered into the Spring application context through a dynamic loading mechanism to form a complete data access chain from the entity layer, mapping layer to the service layer.

[0092] Specifically, the autowiring process first parses the generated entity class code to obtain its complete class definition information, which serves as the entity class type. Simultaneously, it parses the generated data access layer component code to confirm its inheritance from a predefined generic base mapper interface, thus determining its mapper type. Then, based on the entity class type and mapper type, service layer component code is dynamically generated using Java generic parameter binding technology. The core of this generation process lies in the engine automatically generating a corresponding service class based on the predefined standard CRUD method signatures in the mapper type and the bound entity class type. This class encapsulates the proxy call logic for all mapper methods, thus securely associating generic data access operations with specific entity types. The generated service layer component code is also compiled and loaded through a dynamic class loading mechanism and ultimately registered in the Spring application context, forming a complete and immediately usable data access and operation chain encompassing the entity layer, mapping layer, and service layer. This eliminates the need for manually writing or adjusting business layer service code after database table changes, achieving full-stack automated synchronization from database metadata to executable APIs. By using generic-based type-safe binding, potential errors such as data type mismatches are detected at compile time, reducing runtime exceptions common in reflection-based methods and improving code robustness and maintainability. The ability to generate dynamic code is extended from the data model level to the business interface level, enabling the entire application to adaptively adjust to changes in the database structure, thus improving development efficiency and overall agility.

[0093] Step S500: Load entity class code and data access layer component code into the application runtime environment through a dynamic class loading mechanism to replace or register the corresponding class definitions.

[0094] After successfully generating the entity class code and data access layer component code corresponding to the target data table, they need to be seamlessly integrated into the running application environment through a dynamic class loading mechanism to achieve true hot updates. This process of loading the entity class code and data access layer component code into the application runtime environment through a dynamic class loading mechanism to replace or register the corresponding class definitions includes the following steps:

[0095] Step S501: Use the Groovy class loader to compile and load the entity class code and data access layer component code to generate the corresponding first type object.

[0096] Step S502: Register the first type of object to the Spring application context to generate the corresponding Bean definition.

[0097] Step S503: Determine whether there is a second type of object in the Spring application context that corresponds to the target data table. The second type of object is a class object that was registered before the dynamic code generation process was triggered.

[0098] Step S504: If it exists, replace the second type of object with the first type of object through the version control mechanism, and update the Bean definition in the Spring application context to maintain the dependency injection relationship.

[0099] Step S505: If the object does not exist, register and inject the first type of object as a new Bean definition.

[0100] Specifically, upon receiving the generated code string, the initialized Groovy class loader is invoked. This loader first compiles the code string into standard Java bytecode in memory, performing syntax checks and bytecode verification to ensure the code conforms to the JVM specification. After compilation, the loader dynamically locates a new Class object (the first type of object) using the `defineClass` method. This process is entirely in memory, without writing to disk, thus ensuring loading speed and security. The generated first-type object is then constructed into a standard Bean definition using Spring's `BeanDefinitionBuilder`, setting its scope, dependencies, and other properties. These definitions are then dynamically registered in the current Spring application context using `BenaDefinitionRegistry`, bringing them under the management of the `iodine-cluster` container to support subsequent dependency injection. Before registering a new class, the Spring context is queried to check if a Bean definition with the same fully qualified name already exists; the corresponding class instance is the second type of object. If it exists, it means that the corresponding entity and Mapper class have already been loaded, and this is an update operation. If it does not exist, it is the first loading.

[0101] If they exist, the first type of object will be replaced with the second type of object through a version control mechanism. This replacement of the second type of object with the first type of object through version control includes the following steps:

[0102] Step S504-1: Generate a new version identifier for the first type of object and retain the historical version identifier for the second type of object.

[0103] Step S504-2: Based on the new version identifier and the historical version identifier, establish parallel Bean definition registration in the Spring application context, and route newly received business requests to the first type of object corresponding to the version identifier for processing.

[0104] Step S504-3: For existing business requests that have been received but not yet processed by the second type of object, continue to have them processed by the second type of object until completion.

[0105] Step S504-4: After confirming that all existing business requests have been processed and the first column of objects is running stably, remove the corresponding Bean definition of the second type from the Spring application context and reclaim the memory resources it occupies.

[0106] Specifically, the first step is to maintain a version number for each class, such as a timestamp or an incrementing sequence number. In this update, the first type of object is marked as the new version, while the second type of object retains the original version identifier. The second step is to register both the old and new versions of the bean in the Spring container simultaneously. However, through custom routing logic, all newly arriving requests are automatically directed to the new version bean, ensuring that new business logic immediately uses the updated class logic. The third step, to ensure business continuity, ongoing requests are still handled by instances of the old version class. Version associations are maintained through request context or thread-local variables to avoid runtime state conflicts. The fourth step monitors the activity status of the old version instances. Once they have no remaining tasks, their bean definitions are deregistered from the container, and the JVM's garbage collection mechanism is notified to reclaim the relevant class loaders and class instances, completing resource cleanup.

[0107] Finally, for tables loaded for the first time, they are directly registered as new Beans, and a complete dependency chain is established for the business layer to call. This dynamic class loading process based on Groovy class loaders and version control mechanisms achieves zero-restart hot updates of database entity classes and data access layer components. It can dynamically compile, load, and replace class definitions during runtime, synchronizing database structure changes without restarting the application, improving availability and maintenance efficiency. Furthermore, the versioned parallel replacement mechanism ensures business continuity and smooth migration, reducing request failures or state inconsistencies caused by class updates. At the same time, fine-grained memory management guarantees long-term stability and resource efficiency.

[0108] Step S600: After completing the dynamic class loading, update the refresh timestamp information corresponding to the target data table in the local cache.

[0109] After successfully hot-loading the updated entity class and data access layer components to the runtime environment via dynamic class loading, to ensure the accuracy of continuous monitoring and avoid the same change being repeatedly detected and processed, the timestamp status in the local cache needs to be updated promptly and reliably, thus completing a full refresh loop. Updating the refresh timestamp information corresponding to the target data table in the local cache after completing dynamic class loading includes the following steps:

[0110] Step S601: Obtain the identification information of the target data table, and query the database system table based on the identification information to obtain the latest change timestamp of the target data table.

[0111] Step S602: Replace the original refresh timestamp record corresponding to the target data table in the local cache with the latest change timestamp through an atomic write operation.

[0112] Specifically, the unique identifier, typically the table name or internal mapping ID, is first extracted from the context of the target data table after class loading has been completed. Then, through the initialized database connection manager, a precise query is initiated to the system table of the database to obtain only the current last modified timestamp of the target data table. This query is a lightweight operation that does not involve scanning business data tables, ensuring authoritative and real-time version information is obtained with low overhead, providing an accurate basis for subsequent cache updates. After obtaining the latest change timestamp, an atomic update operation is performed. This operation is typically implemented in the memory cache using a CAS (Compare-And-Swap) mechanism or distributed locks, ensuring that the refresh timestamp of the same data table is successfully updated only once in a concurrent environment, avoiding timestamp overwriting or state inconsistency due to thread contention. After the update, this timestamp serves as the benchmark for subsequent change detection, marking that the structural change has been fully synchronized by the application. In this way, by precisely and atomically updating the cache timestamp, a closed loop of consistent synchronization and detection of change states is achieved. This ensures that each structural change triggers code generation and loading only when it is first identified, avoiding invalid duplicate operations and improving overall efficiency and resource utilization. Meanwhile, atomic writing ensures the accuracy and reliability of timestamp data in high-concurrency scenarios, providing a stable and reliable state foundation for continuous monitoring, and supporting the entity refresh capability with zero restart and high availability.

[0113] Figure 2 This is a schematic diagram of the system architecture for the database entity refresh operation provided in this application. For example... Figure 2As shown, the system includes a database monitoring module, a Groovy code generation engine, a dynamic loading manager, a cache management module, a change detector, and CRUD interface autowiring. The database monitoring module continuously monitors changes to the database table structure by periodically querying the database system tables to obtain the last modification timestamps of each table. The change detector identifies target tables with structural changes based on a timestamp comparison mechanism. The Groovy code generation engine dynamically generates entity class code and data access layer component code based on the target table's structure metadata and predefined code generation templates. The dynamic loading manager compiles and loads the generated code using the Groovy class loader and injects it into the Spring application context, enabling hot replacement or new registration of classes. The cache management module maintains the refresh timestamps of each table and multi-level caching strategies, supporting efficient change detection and state synchronization. The CRUD interface autowiring, based on the generated entity classes and data access layer components, automatically assembles complete type-safe data operation interfaces and registers them with the Spring context, forming a complete data access chain from the entity layer, mapping layer, to the service layer. These modules work together to achieve real-time detection of database table structure changes, automatic code generation, and hot updates without requiring application restarts.

[0114] Figure 3 This is a flowchart illustrating a database entity refresh method provided in this application. Figure 3 As shown, after the application starts, it first performs system initialization operations, including establishing a database connection pool, creating a Groovy class loader instance, initializing a multi-level cache manager, and scanning all table structure information in the database, while loading predefined code generation templates. Next, based on the scanned table structure metadata, Groovy dynamically generates entity classes conforming to the JavaBean specification, data access layer component code inheriting from the generic basic mapper interface, and service layer component code implementing generic CRUD operations. The generated code is then loaded into the JVM through a dynamic class loading mechanism, and the corresponding refresh timestamp is recorded in the cache. Afterwards, it receives database operation requests, queries the most recent change time of the corresponding data table, compares it with the refresh time recorded in the cache, and if the change time is not later than the refresh time, it directly executes the database operation and returns the operation structure. If the change time is later than the refresh time, Groovy is triggered to regenerate the corresponding entity classes, data access layer components, and service layer component code, dynamically replacing class instances through the dynamic class loading mechanism, updating the corresponding refresh timestamp in the cache, executing the database operation, and returning the operation result.

[0115] Figure 4 This is a schematic diagram of a database entity refresh system connection provided in an embodiment of this application. For example... Figure 4As shown, a database entity refresh system includes: a monitoring module, a processing module, a response module, and a refresh module.

[0116] The system comprises the following modules: a monitoring module to monitor database table structure changes and obtain structural metadata and corresponding last change timestamps for each table; a processing module to compare each last change timestamp with the corresponding refresh timestamp in the local cache and determine the target table whose structure has changed; a response module to trigger a dynamic code generation process for the target table; and a refresh module to dynamically generate entity class code and data access layer component code corresponding to the target table based on the target structure metadata and predefined code generation templates. The module loads the entity class code and data access layer component code into the application runtime environment using a dynamic class loading mechanism to replace or register the corresponding class definitions. After completing the dynamic class loading, it updates the refresh timestamp information corresponding to the target table in the local cache.

[0117] The other functions performed by the monitoring module, processing module, response module, and refresh module, as well as the technical details of each function, are the same as or similar to the corresponding features in the database entity refresh method described above, so they will not be repeated here.

[0118] This application also provides a computer storage medium storing a computer program that, when run on a computer, enables the computer to execute the steps in the database entity refresh method described above.

[0119] It should be understood that although the steps in the flowcharts in the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order requirement for the execution of these steps, and they may be performed in other orders.

[0120] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A database entity refresh method, characterized in that, The method includes: Monitor changes to the database table structure to obtain the structural metadata of each table and the corresponding last change timestamp; Each of the last change timestamps is compared with the corresponding refresh timestamp in the local cache, and the target data table whose structure has changed is determined based on the comparison. In response to the target data table, a dynamic code generation process for the target data table is triggered; Based on the target structure metadata of the target data table and the predefined code generation template, the entity class code and data access layer component code corresponding to the target data table are dynamically generated. The entity class code and data access layer component code are loaded into the application runtime environment through a dynamic class loading mechanism to replace or register the corresponding class definitions. After the dynamic class loading is completed, update the refresh timestamp information in the local cache corresponding to the target data table.

2. The method according to claim 1, characterized in that, The predefined code generation templates include predefined entity class code templates and predefined data access layer component templates. The dynamic generation of entity class code and data access layer component code corresponding to the target data table based on the target structure metadata of the target data table and the predefined code generation templates includes: Parse the target structure metadata to obtain the table name, field name, field type, and constraint information of the target data table; The table name, field name, field type, and constraint information are combined with a predefined entity class code template to generate entity class code that conforms to the JavaBean specification and includes corresponding field definitions and annotations; Based on the entity class code and the predefined data access layer component template, data access layer component code is generated that integrates with the general basic mapper interface and corresponds to the target data table. The data access layer component code includes generic parameter declarations based on the entity class code.

3. The method according to claim 2, characterized in that, The step of loading the entity class code and data access layer component code into the application runtime environment through a dynamic class loading mechanism to replace or register the corresponding class definitions includes: The entity class code and data access layer component code are compiled and loaded using the Groovy class loader to generate the corresponding first type of object; Register the first type of object to the Spring application context to generate the corresponding Bean definition; Determine whether a second type of object corresponding to the target data table exists in the Spring application context, wherein the second type of object is a class object that was registered before the dynamic code generation process was triggered; If they exist, the first type of object is replaced with the second type of object through a version control mechanism, and the Bean definition in the Spring application context is updated to maintain the dependency injection relationship; If it does not exist, register and inject the first type of object as a new Bean definition.

4. The method according to claim 1, characterized in that, The step of updating the refresh timestamp information corresponding to the target data table in the local cache after the dynamic class loading is completed includes: Obtain the identification information of the target data table, and query the database system table based on the identification information to obtain the latest change timestamp of the target data table; The latest change timestamp is used to replace the original refresh timestamp record corresponding to the target data table in the local cache through an atomic write operation.

5. The method according to claim 1, characterized in that, The monitoring of database table structure changes to obtain the structure metadata of each data table and the corresponding last change timestamp includes: Periodically query the database system tables to obtain a set of version information containing the last modification timestamp of each data table; The version information set is compared with the version information cached in the previous period to filter out the data table whose last modification timestamp has been updated as the table to be checked; Obtain the current complete structural metadata of the table to be checked, and compare it with the pre-stored historical structural metadata to identify the type of structural change; When the structural change type is identified, the last modification timestamp is used as the valid last change timestamp.

6. The method according to claim 1, characterized in that, The method further includes: Read a set of system configuration parameters, including database connection parameter group, code generation parameter group, cache management parameter group, and performance tuning parameter group, from a predefined configuration source; Initialize the database connection manager instance based on the database connection parameter group; The instantiation parameters of the predefined code generation template are initialized based on the code generation parameter group; The storage and invalidation policies of the local cache are initialized based on the cache management parameter group. Initialize the thread pool and batch processing parameters involved in the monitoring, dynamic code generation, and dynamic class loading processes based on the performance tuning parameter group; Apply the initialized manager instances and parameter configurations to the corresponding modules.

7. The method according to claim 3, characterized in that, The step of replacing the second type of object with the first type of object through a version control mechanism includes: Generate a new version identifier for the first type of object and retain historical version identifiers for the second type of object; Based on the new version identifier and the historical version identifier, parallel Bean definition registration is established in the Spring application context, and newly received business requests are routed to the first type of object corresponding to the new version identifier for processing; For existing business requests that have been received by the second type of object but have not yet been processed, they will continue to be processed by the second type of object until they are completed. After confirming that all existing business requests have been processed and the first column objects are running stably, the corresponding Bean definition of the second type is removed from the Spring application context and its occupied memory resources are reclaimed.

8. The method according to claim 2, characterized in that, The method further includes: Based on the entity class code and data access layer component code, the complete CRUD operation interface corresponding to the target data table is automatically assembled. The automated assembly includes: Parse the entity class code to obtain the entity class type, and unlock the data access layer component code to obtain the mapper type integrated from the general basic mapper interface; Based on the entity class type and the mapper type, type binding is performed through the Java generic parameters declared in the data access layer component code to generate type-safe service layer component code, wherein the service layer component code encapsulates the calling logic of the predefined CRUD methods in the mapper type; The service layer component code is loaded and registered into the Spring application context through the dynamic class loading mechanism to form a complete data access chain from the entity layer, mapping layer to the service layer.

9. A database entity refresh system, characterized in that, The system includes: a monitoring module, a processing module, a response module, and a refresh module; wherein, The monitoring module is used to monitor changes in the database table structure to obtain the structural metadata of each data table and the corresponding last change timestamp. The processing module is used to compare each of the last change timestamps with the corresponding refresh timestamps in the local cache, and determine the target data table whose structure has changed based on the comparison. The response module is used to trigger a dynamic code generation process for the target data table in response to the target data table; The refresh module is used to dynamically generate entity class code and data access layer component code corresponding to the target data table based on the target structure metadata of the target data table and a predefined code generation template; load the entity class code and data access layer component code into the application runtime environment through a dynamic class loading mechanism to replace or register the corresponding class definitions; and update the refresh timestamp information corresponding to the target data table in the local cache after the dynamic class loading is completed.

10. A computer-readable storage medium having a computer program stored thereon that can run on a processor, characterized in that, When the computer program is executed by the processor, it implements a database entity refresh method as described in any one of claims 1 to 8.

Images