Data processing method and apparatus, storage medium, and electronic device

Abstract

The application provides a data processing method and device, a storage medium and an electronic equipment, a database access layer method of intercepted calling is based on metadata parsed from parameter annotation information of the database access layer method, table splitting parameters, table splitting attribute values and table splitting additional information values are obtained from calling information of the database access layer method; in a table splitting strategy, based on the table splitting attribute values, the table splitting additional information values and the database access layer method information, index calculation is performed on the table splitting attribute values; the table splitting parameters are reconstructed by using the calculated table splitting indexes, and the table splitting indexes are stored in a table splitting context; based on the table splitting indexes in the table splitting context, logical table names of original SQL statements are replaced by actual table names to generate final SQL statements, and a database access result of the final SQL statements is aggregated to obtain a final calling result of the database access layer method. The application can realize table splitting reconstruction without changing the system, and improve the table splitting efficiency of data.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a data processing method and apparatus, a storage medium and an electronic device. Background Technology

[0002] As the system application operates, the amount of business data will increase significantly with the development of business, potentially reaching tens of millions or even hundreds of millions of records. If the system uses single-table storage, storing tens of millions of records will often affect data query performance, thereby impacting the availability of system services and user experience. In such cases, the system typically employs database sharding and table partitioning, especially horizontal table partitioning.

[0003] Currently, horizontal partitioning of data requires specific partitioning parameters of a particular name or type, and also necessitates changes to the system's interface specifications. Otherwise, it cannot support the partitioning transformation of existing systems, resulting in low efficiency in data partitioning. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a data processing method and apparatus, a storage medium and an electronic device. By applying the present invention, table partitioning can be performed without modifying the system to partition tables, thereby improving the efficiency of table partitioning.

[0005] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions:

[0006] A data processing method, comprising:

[0007] The currently invoked database access layer method is intercepted by a pre-defined first interceptor;

[0008] The parameter annotation information of the database access layer method is parsed to obtain the metadata of the database access layer method. The metadata includes a method entity mapping table, a method parameter name parser mapping table, a table partitioning information mapping table, and an additional information mapping table.

[0009] Based on the metadata of the database access layer method, obtain the table partitioning parameters, table partitioning attribute values, and table partitioning additional information values ​​from the call information of the database access layer method;

[0010] The table partitioning strategy is obtained based on the table partitioning strategy name of the database access layer method. In the table partitioning strategy, the table partitioning attribute value is indexed based on the table partitioning attribute value, the table partitioning additional information value and the database access layer method information to obtain the table partitioning index result of the table partitioning attribute value.

[0011] Based on the table partitioning index result, the table partitioning parameters are reconstructed to obtain each reconstructed table partitioning parameter and the table partitioning index of each reconstructed table partitioning parameter, and the table partitioning index of each reconstructed table partitioning parameter is saved to a preset table partitioning context.

[0012] By using a pre-defined second interceptor based on each table index in the table partitioning context, the logical table name of the SQL statement corresponding to each reconstructed table partitioning parameter is replaced with the actual table name, so that each reconstructed table partitioning parameter can access the database based on the actual table name of the SQL statement, and obtain the database access result of each reconstructed table partitioning parameter.

[0013] The database access results of each reconstructed table parameter are aggregated to obtain the final call result of the database access layer method.

[0014] A data processing apparatus, comprising:

[0015] The interception unit is used to intercept the currently invoked database access layer method through a preset first interceptor;

[0016] The parsing unit is used to parse the parameter annotation information of the database access layer method and obtain the metadata of the database access layer method. The metadata includes a method entity mapping table, a method parameter name parser mapping table, a table partitioning information mapping table, and an additional information mapping table.

[0017] The acquisition unit is used to acquire the table partitioning parameters, table partitioning attribute values, and table partitioning additional information values ​​from the call information of the database access layer method based on the metadata of the database access layer method.

[0018] The calculation unit is used to obtain the table partitioning strategy based on the table partitioning strategy name of the database access layer method. In the table partitioning strategy, the table partitioning attribute value is indexed based on the table partitioning attribute value, the table partitioning additional information value and the database access layer method information to obtain the table partitioning index result of the table partitioning attribute value.

[0019] The reconstruction unit is used to reconstruct the table partitioning parameters based on the table partitioning index result, to obtain each reconstructed table partitioning parameter and the table partitioning index of each reconstructed table partitioning parameter, and to save the table partitioning index of each reconstructed table partitioning parameter to a preset table partitioning context.

[0020] The replacement unit is used to replace the logical table name of the SQL statement corresponding to each of the reconstructed table parameters with the actual table name based on each of the table indexes in the table partitioning context through a preset second interceptor, so that each of the reconstructed table parameters can access the database based on the actual table name of the SQL statement and obtain the database access result of each of the reconstructed table parameters.

[0021] The aggregation unit is used to aggregate the database access results of each reconstructed table parameter to obtain the final call result of the database access layer method.

[0022] A storage medium comprising stored instructions, wherein, when the instructions are executed, the device in which the storage medium resides executes the data processing method described above.

[0023] An electronic device includes a memory and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors using the data processing method described above.

[0024] Compared with the prior art, the present invention has the following advantages:

[0025] The present invention provides a data processing method, apparatus, storage medium, and electronic device. A first interceptor intercepts the currently invoked database access layer method, parses the parameter annotation information of the database access layer method to obtain its metadata, and, based on this metadata, retrieves sharding parameters, sharding attribute values, and sharding additional information values ​​from the method's invocation information. The sharding strategy is then obtained based on the sharding strategy name of the database access layer method, and within this strategy, the sharding attribute values ​​are indexed based on the sharding attribute values, sharding additional information values, and the database access layer method information. The process involves calculating the table partitioning index results for the partitioning attribute values. Based on these index results and attribute values, the table partitioning parameters are reconstructed, resulting in each reconstructed parameter and its associated index. The index for each parameter is saved to the partitioning context. This allows the second interceptor to replace the logical table name in the SQL statement for each parameter with the actual table name, enabling database access for each parameter based on the actual table name in the SQL statement. The database access results are then aggregated to obtain the final call result of the database access layer method. This invention achieves table partitioning without requiring system modifications, thereby improving data partitioning efficiency. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0027] Figure 1 A flowchart of a data processing method provided in an embodiment of the present invention;

[0028] Figure 2 A flowchart illustrating a method for parsing annotation information of database access layer methods to obtain metadata of database access layer methods, as provided in an embodiment of the present invention.

[0029] Figure 3 This is a flowchart of a method for obtaining table partitioning parameters, table partitioning attribute values, and table partitioning additional information values ​​provided in an embodiment of the present invention.

[0030] Figure 4 An architecture diagram illustrating the implementation principle of a data processing method provided by this invention;

[0031] Figure 5 An organizational structure diagram of a data processing method provided in an embodiment of the present invention;

[0032] Figure 6 This is a schematic diagram of the structure of a data processing device provided in an embodiment of the present invention;

[0033] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0034] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0035] In this application, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0036] As the system application operates, the amount of business data will increase significantly with the development of business, potentially reaching tens of millions or even hundreds of millions of records. If the system uses single-table storage, storing tens of millions of records will often affect data query performance, thereby impacting the availability of system services and user experience. In such cases, the system typically employs database sharding and table partitioning, especially horizontal table partitioning.

[0037] There are currently two methods for horizontal table partitioning. Method 1: Using a table partitioning index placeholder scheme, the table partitioning index for relevant data is calculated at the business layer and then passed through to the Mapper layer and the underlying Mybatis for table partitioning index replacement. Method 2: Using the Mybatis-StatementHandler interceptor, the table partitioning index is calculated based on specific business data or non-business data (such as the current month or year) in the interceptor, and then the logical table name is replaced. This method requires the input parameters to contain table partitioning parameters with specific names or types.

[0038] When the system adopts a table partitioning index placeholder scheme, the table partitioning index needs to be calculated in the business logic, table partitioning index parameters need to be added to various layered methods in the system, and table partitioning index placeholders need to be added to the mapper.xml file. This couples the table partitioning logic with the business logic. For new business processes that require table creation, or existing business processes that need to be expanded, table partitioning-related logic needs to be added to the business logic. This leads to unclear code logic, limited scalability, and developers being unable to focus on business logic development, impacting development efficiency and code quality.

[0039] When using the Mybatis-StatementHandler interceptor solution, this approach primarily intercepts the StatementHandler's prepare method. By parsing specific names or types of sharding parameters, it calculates the sharding index and then replaces the logical table name in the SQL statement. Therefore, for existing systems with inconsistent sharding parameters, the workload for sharding modification is substantial, requiring the unification of sharding parameters. Furthermore, this approach targets SQL statements. For operations such as IN queries, batch modifications, and batch inserts, not only the logical table name in the SQL statement needs to be modified, but also the parameter placeholders. The modification of parameter placeholders, in particular, involves an uncontrollable workload and risk. Therefore, this approach currently only supports single-row operations and does not support batch operations, resulting in low sharding efficiency.

[0040] This invention can be used in numerous general-purpose or special-purpose computing device environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor devices, and distributed computing environments including any of the above devices. This invention can be applied to horizontal table partitioning devices built on Mybatis. By using the method provided by this invention, table partitioning can be performed without modifying the system, improving partitioning efficiency.

[0041] Reference Figure 1 The following is a flowchart of a data processing method provided in an embodiment of the present invention, which is described in detail below:

[0042] S101. Intercept the currently called database access layer method through the preset first interceptor.

[0043] The first interceptor in this invention is the Executor interceptor. The Executor interceptor receives the data processing request sent by the data persistence layer and can determine the database access layer method through the data processing request. It should be noted that the database access layer method in this invention is the Mapper method. In the description of this article, the Mapper method is the database access layer method.

[0044] S102. Parse the parameter annotation information of the database access layer method to obtain the metadata of the database access layer method. The metadata includes the method entity mapping table, the method parameter name resolver mapping table, the table partitioning information mapping table, and the additional information mapping table.

[0045] The annotation information of database access layer methods can be understood as the table partitioning information of the database access layer methods, including but not limited to table partitioning parameter annotations and additional information annotations.

[0046] The parsing of annotation information in database access layer methods mainly involves four aspects: parsing of method entities, parsing of method parameter name resolvers, parsing of table partitioning information, and parsing of additional information.

[0047] It should be noted that the method entity mapping table in the metadata can also be called the method name -> method entity mapping table; the method parameter name resolver mapping table can be called the method name -> method parameter name resolver mapping table; the partition information mapping table can be called the method name -> partition information mapping table; and the additional information mapping table can be called the method name -> additional information mapping table.

[0048] It should be noted that, referring to Figure 2 The following is a flowchart illustrating a method for parsing parameter annotation information of a database access layer method to obtain its metadata, as provided in this embodiment of the invention:

[0049] S201. The first interceptor obtains the first parameter in the parameter array property of the call information and obtains the underlying encapsulated object based on the first parameter.

[0050] It should be noted that the underlying encapsulated object is a MappedStatement object, that is, the MappedStatement object is obtained based on the first parameter.

[0051] S202. Parse the identity attributes of the underlying encapsulated object to obtain the fully qualified class name and method name.

[0052] Preferably, the identity attribute can be represented as an id attribute. The id attribute of the MappedStatement object is parsed to obtain the fully qualified class name and method name.

[0053] S203. Obtain the bytecode object corresponding to the fully qualified class name, determine the method entity corresponding to the method name in the bytecode object, cache the determined method entity, and obtain the method entity mapping table.

[0054] It should be noted that the bytecode object is a class object, that is, to obtain the class object corresponding to the fully qualified class name.

[0055] S204. Obtain the method parameter name resolver based on the underlying encapsulated object, cache the method parameter name resolver, and obtain the method parameter name resolver mapping table.

[0056] S205. Obtain the table partitioning parameter annotation information of the database access layer method from the parameter annotation information. Based on the table partitioning parameter annotation information, parse the table partitioning parameters and table partitioning attributes of the database access layer method to obtain the table partitioning information. Cache the table partitioning information to obtain the table partitioning information mapping table.

[0057] S206. From the parameter annotation information of the database access layer method, the table partitioning additional parameter annotation information is extracted. Based on the table partitioning additional parameter annotation information, the table partitioning additional parameters of the database access layer method are parsed to obtain the table partitioning additional information. The table partitioning additional information is then cached to obtain the additional information mapping table.

[0058] This invention parses the parameter annotation information of the called database access layer method to obtain the metadata of the database access layer method. The metadata contains table-related information of the database access layer method, such as the mapping relationship between the method name and the method entity object, and the mapping relationship between the method name and the method parameter name resolver, which can avoid multiple parsing.

[0059] S103. Based on the metadata of the database access layer methods, obtain the table partitioning parameters, table partitioning attribute values, and table partitioning additional information values ​​from the call information of the database access layer methods.

[0060] Reference Figure 3 The flowchart below shows a method for obtaining table partitioning parameters, table partitioning attribute values, and table partitioning additional information values ​​according to an embodiment of the present invention. The details are as follows:

[0061] S301. The first interceptor obtains the second parameter from the parameter array attribute of the call information, determines the parameter value of the database access layer method from the second parameter, and processes the parameter value using the method parameter name resolver mapping table in the metadata of the database access layer method to obtain the parameter array.

[0062] It should be noted that the call information refers to the call information of the database access layer method.

[0063] S302. Use the table partitioning information mapping table in the metadata of the database access layer method to obtain the table partitioning parameter index of the database access layer method.

[0064] S303. Based on the database access layer method, the table parameter index and parameter array are used to obtain the table parameters.

[0065] S304. Determine the table partitioning scenario for the table partitioning parameters, and obtain the table partitioning information corresponding to the table partitioning scenario. The table partitioning scenario can be one of the following: array, list, set, or single object.

[0066] It should be noted that in the table partitioning scenario of this invention, lists can be represented by List, and collections can be represented by Set.

[0067] S305. Based on the table partitioning information, execute the table partitioning process corresponding to the table partitioning scenario to obtain the table partitioning attribute values.

[0068] S306. Obtain the table-specific additional information value based on the additional information mapping table in the metadata of the parameter array and database access layer method.

[0069] It should be noted that the content of the table partitioning information differs for different table partitioning scenarios, and the table partitioning process also differs for different scenarios. For example, when the table partitioning scenario is an array, the partitioning information includes the table parameter type, the table attribute type, whether the table attribute exists, and the table attribute name; when the table partitioning scenario is a List, the partitioning information includes the table parameter generic type, the table attribute type, whether the table attribute exists, and the table attribute name; when the table partitioning scenario is a Set, the partitioning information includes the table parameter generic type, the table attribute type, whether the table attribute exists, and the table attribute name; when the table partitioning scenario is a single object, the partitioning information includes the table parameter type, whether the table attribute is an array, whether the table attribute is a collection, the table attribute type, the table attribute generic type, and whether the table attribute exists.

[0070] S104. Obtain the table partitioning strategy based on the table partitioning strategy name of the database access layer method. In the table partitioning strategy, perform index calculation on the table partitioning attribute values ​​based on the table partitioning attribute values, the table partitioning additional information values ​​and the database access layer method information to obtain the table partitioning index result of the table partitioning attribute values.

[0071] It should be noted that the process of obtaining the sharding strategy based on the sharding strategy name of the database access layer method is as follows: obtain the sharding information of the database access layer method from the sharding information mapping table; and obtain the sharding strategy from the sharding strategy manager based on the sharding strategy name in the sharding information.

[0072] Preferably, the table partitioning attribute value here has multiple values, and the table partitioning index result here includes List<single table partitioning attribute value> and the table partitioning index.

[0073] Preferably, the table partitioning index result that satisfies the preset structure can be: Map<table partitioning index, List<single table attribute value>>, and further, List<single table attribute value>> is a heaped result.

[0074] S105. Based on the results of the partitioned table index and the partitioned table attribute values, the partitioned table parameters are reconstructed to obtain each reconstructed partitioned table parameter and the partitioned table index of each reconstructed partitioned table parameter, and the partitioned table index of each reconstructed partitioned table parameter is saved to the preset partitioned table context.

[0075] It should be noted that the specific process of reconstructing the table partitioning parameters based on the table partitioning index results and table partitioning attribute values ​​to obtain each reconstructed table partitioning parameter is as follows: determine whether the table partitioning parameter supports table partitioning based on the table partitioning information; when it is determined that the table partitioning parameter supports table partitioning, apply the stacking result in the table partitioning index results to split the table partitioning parameter to obtain each reconstructed table partitioning parameter; and determine the table partitioning index of each reconstructed table partitioning parameter based on the table partitioning index information in the stacking result.

[0076] Preferably, the partitioning parameter contains multiple partitioning values, and each reconstructed partitioning parameter obtained after reconstruction contains at least one partitioning value. One reconstructed partitioning parameter corresponds to one partitioning index, and each partitioning value in the reconstructed partitioning parameter corresponds to the same partitioning index.

[0077] After obtaining the partition index for each refactored partition parameter, save each partition index to the partition context.

[0078] Furthermore, if it is determined that the table partitioning parameter does not support table partitioning, an exception message will be thrown to indicate that the table partitioning parameter does not support table partitioning.

[0079] S106. Using a pre-defined second interceptor, based on the various table indexes in the table partitioning context, the logical table name of the Structured Query Language (SQL) statement corresponding to each reconstructed table partitioning parameter is replaced with the actual table name, so that each reconstructed table partitioning parameter can access the database based on the actual table name of the SQL statement, and obtain the database access result of each reconstructed table partitioning parameter.

[0080] The second interceptor in this invention is the StatementHandler interceptor. It should be noted that each partitioning attribute value in the reconstructed partitioning parameters corresponds to the same Structured Query Language (SQL) statement. The SQL statement in this paper can also be called the partitioning SQL statement. The StatementHandler interceptor replaces the logical table name of the SQL statement with the actual table name based on the various partitioning indexes in the partitioning context, so that each reconstructed partitioning parameter can access the database using the actual table name of the corresponding SQL statement to obtain the database access result.

[0081] S107. Aggregate the database access results of each restructured table parameter to obtain the final call result of the database access layer method.

[0082] In the method provided by this invention, a first interceptor intercepts the currently invoked database access layer method, parses the parameter annotation information of the database access layer method to obtain its metadata, and based on the metadata, retrieves the sharding parameters, sharding attribute values, and sharding additional information values ​​from the method's invocation information. The method then retrieves the sharding strategy based on the sharding strategy name of the database access layer method. Within the sharding strategy, the method performs index calculations on the sharding attribute values ​​based on the sharding attribute values, sharding additional information values, and the database access layer method information to obtain the sharding attribute values. The system obtains the table partitioning index results; based on the table partitioning index results and table attribute values, the table partitioning parameters are reconstructed to obtain each reconstructed table partitioning parameter and its corresponding table partitioning index. The table partitioning index of each reconstructed table partitioning parameter is saved to the table partitioning context. This allows the second interceptor to replace the logical table name in the SQL statement for each reconstructed table partitioning parameter with the actual table name, enabling each reconstructed table partitioning parameter to access the database based on the actual table name in the SQL statement, thus obtaining the database access result for each reconstructed table partitioning parameter. The database access results are then aggregated to obtain the final call result of the database access layer method. This invention achieves table partitioning transformation without modifying the system, thereby improving the efficiency of data partitioning.

[0083] Reference Figure 4 This is an architecture diagram illustrating the implementation principle of the method provided by the present invention. Based on Mybatis, this architecture employs parameter dimension annotations, Executor interceptors, and StatementHandler interceptors for table partitioning. This solution not only decouples the table partitioning logic from the business logic, allowing developers to focus solely on the business logic, but also enables rapid table partitioning transformation for existing systems with inconsistent partitioning parameters. Furthermore, it provides excellent support for batch operations on arrays and lists, such as IN queries, batch inserts, and batch updates.

[0084] This invention is achieved through Figure 4The solution provided in this invention is implemented using parameter-dimensional table partitioning annotations, Executor interceptors, and StatementHandler interceptors. Parameter-dimensional table partitioning annotations apply to the table partitioning parameters of Mapper methods, identifying which parameter or parameter attribute the method uses for table partitioning index calculation. The Executor interceptor intercepts the query and update methods of the Executor, primarily including four core functions: table partitioning parameter parsing, table partitioning index calculation, table partitioning parameter reconstruction, and table partitioning result aggregation. Table partitioning parameter parsing mainly involves parsing the table partitioning parameters of the Mapper methods (i.e., parameters containing table partitioning parameter annotations) to obtain the table partitioning attribute values ​​participating in the table partitioning index calculation, while simultaneously saving the table partitioning information to the metadata registry during the parsing process. Table partitioning index calculation mainly involves... The system calculates the sharding index corresponding to the sharding attribute value based on the specific implementation of the sharding strategy SPI provided externally; sharding parameter reconstruction mainly involves reconstructing the sharding parameters based on the sharding index and sharding attribute value, especially when the sharding parameters are array and collection type parameters, the arrays and collections need to be split and heaped; sharding result aggregation mainly involves aggregating the database access results after the sharding parameter reconstruction; the StatementHandler interceptor intercepts the StatementHandler's prepare method, mainly including table name replacement functionality, that is, changing the logical table name to the actual table name based on the sharding index calculated by the Executor interceptor.

[0085] This solution uses parameter dimension annotations, Executor interceptors, and StatementHandler interceptors. Based on parameter dimension annotations, only the table partitioning parameters need to be annotated at the Mapper layer. Moreover, the table partitioning index is calculated uniformly in the interceptor, without needing to be calculated in the business logic. The entire solution has low intrusion into the business logic and achieves decoupling from the business logic.

[0086] This solution uses parameter-level annotations, which can flexibly annotate the table partitioning parameters on the Mapper methods. This allows for rapid support of table partitioning transformations in existing systems without the need to standardize the names or types of table partitioning parameters or modify interface specifications. By intercepting the query and update methods of the Executor, this solution splits and reconstructs the table partitioning parameters of the methods before generating BoundSql. Then, by leveraging Mybatis' existing BoundSql generation function, dynamic SQL is converted into static or native SQL without the need for manual parsing and modification of SQL. This elevates the table partitioning process from reconstructing SQL statements to reconstructing method parameters, thus enabling rapid and stable support for batch table partitioning scenarios.

[0087] The core of this solution is: 1) Define parameter dimension annotations to mark the table partitioning parameters on the Mapper methods; 2) Implement an Executor interceptor. In this interceptor, firstly, the table partitioning parameters are parsed to obtain the table partitioning attribute values ​​participating in the table partitioning index calculation, as well as the table partitioning information metadata of each Mapper method; secondly, the table partitioning index is calculated based on the table partitioning strategy based on the table partitioning attribute values; then, the table partitioning parameters are split and reconstructed based on the table partitioning index and the table partitioning attribute values; finally, the database access results of each table partition are aggregated; 3) Implement a StatementHandler interceptor. In this interceptor, the table names of each table partition are replaced, that is, the logical table names are replaced with the actual table names.

[0088] In this solution, we mainly use three components to implement a general horizontal table partitioning mechanism: table partitioning annotations, Executor interceptors, and StatementHandler interceptors.

[0089] Reference Figure 5 This is an organizational structure diagram of a data processing method provided in an embodiment of the present invention. The diagram includes three components: table partitioning annotation definition, Executor interceptor, and StatementHandler interceptor.

[0090] The table partitioning annotation definition mainly defines table partitioning parameter annotations and additional information annotations. Table partitioning parameter annotations are mainly used to mark the parameters of the Mapper method that are used for table partitioning. Additional information annotations are mainly used to mark the parameters of the Mapper method that need to participate in the table partitioning index calculation. Additional information is not a core table partitioning parameter and is used for testing or volume splitting scenarios. In the table partitioning strategy, the table partitioning index is calculated based on the table partitioning attribute values ​​and additional information values ​​obtained from the table partitioning parameters.

[0091] The Executor interceptor elevates the table partitioning process from refactoring SQL statements to refactoring method parameters. It primarily comprises six components: metadata management, partitioning strategy management, partitioning parameter parsing, partitioning index calculation, partitioning parameter reconstruction, and partitioning result aggregation. Metadata management mainly parses and caches partitioning-related information for Mapper methods, such as the mapping between method names and method entity objects, and the mapping between method names and method parameter name resolvers, avoiding multiple parsing steps. Partitioning strategy management loads and caches partitioning strategies for various business tables for partitioning index calculation. Partitioning parameter parsing parses partitioning parameters for Mapper methods to obtain partitioning attribute values. Partitioning index calculation, based on the partitioning strategy, performs partitioning index calculation and grouping based on partitioning attribute values. Partitioning parameter reconstruction splits and refactors partitioning parameters based on partitioning indexes and partitioning attribute values, grouping parameters with the same partitioning index, especially for collection and array type partitioning parameters. Partitioning result aggregation aggregates the database access results after partitioning parameter reconstruction.

[0092] The StatementHandler interceptor primarily defines a logical table name converter, used to replace the logical table name in a split SQL statement with the actual table name.

[0093] It should be noted that the table partitioning annotation definition mainly defines the table partitioning parameter annotation and the additional information annotation. The table partitioning parameter annotation is mainly used to mark the parameters of the Mapper method that are used for table partitioning, while the additional information annotation is mainly used to mark the parameters of the Mapper method that need to participate in the table partitioning index calculation.

[0094] Further explanation of the annotations for table partitioning parameters:

[0095] In the program, the parameter annotation for table partitioning can be named @ShardingField. It is mainly used to annotate the parameters for table partitioning on the Mapper method. The annotation information includes the partitioning attributes, the base table name, the partitioning format, and the partitioning strategy.

[0096] To avoid configuring the base table name, partitioning format, and partitioning strategy on each Mapper method, an annotation named @ShardingTable is defined at the Mapper interface level.

[0097] The data priority between the two is that @ShardingField takes precedence over @ShardingTable. That is, if both are configured with information such as base table name, table partitioning format and table partitioning strategy, the configuration information of @ShardingField will be used first.

[0098] For example, the definition of @ShardingField is as follows:

[0099] / / Table partitioning parameter annotation definition, applied to the parameter dimension of Mapper interface method

[0100] / / i.e., PARAMETER dimension

[0101] @ShardingField{

[0102] / / Table partitioning attributes

[0103] String value()default"";

[0104] / / Basic table name

[0105] String base() default "";

[0106] / / Table partitioning format

[0107] String format()default"";

[0108] / / Table partitioning strategy

[0109] String strategy()default"";

[0110] }

[0111] / / Mapper interface dimension annotation definition, applied to Mapper interface dimension

[0112] / / i.e., TYPE dimension

[0113] @ShardingTable{

[0114] / / Basic table name

[0115] String base() default "";

[0116] / / Table partitioning format

[0117] String format()default"";

[0118] / / Table partitioning strategy

[0119] String strategy()default"";

[0120] }

[0121] Setting the value: If the partitioning parameter of the Mapper interface method is a simple data type, an array of simple data types, or a collection, then the value of @ShardingField does not need to be assigned; if the partitioning parameter is a reference data type, an array of reference data types, or a collection, then the value of @ShardingField is assigned to the partitioning attribute in the reference data type, and multi-level partitioning attribute setting is supported, which is similar to OGNL expressions.

[0122] The base value is set to the logical table name.

[0123] The format value is set to a prefix for the actual table name;

[0124] The `strategy` setting specifies the name of the table partitioning strategy, indicating which partitioning strategy to use for table partitioning index calculation.

[0125] The following example illustrates the annotation for table partitioning parameters. All other functional examples below will be based on this example.

[0126] / / OrderMapper is the order DAO class, used for database operations on orders.

[0127] @ShardingTable(base="tbl_order", format="tbl_order_", strategy="orderShardingStrategy")

[0128] OrderMapper{

[0129] / / Order Insert

[0130] int insert(@ShardingField("id")

[0131] @ShardingAddition(value="pin",mapkey="pin")

[0132] @Param("order")OrderPO order);

[0133] }

[0134] / / Order entity class, used for mapping to the order table in the database.

[0135] OrderPO{

[0136] / / Order ID

[0137] Long id;

[0138] / / Place order pin

[0139] String pin;

[0140] / / Order Amount

[0141] Long amount;

[0142] / / Order time

[0143] Date submitTime;

[0144] ...

[0145] }

[0146] For example, tbl_order uses a partitioned table for storage, and its corresponding persistent entity class is OrderPO. The order table is partitioned based on the order ID. During the volume splitting phase, the order ID range is used for volume splitting. In order to facilitate testing and ensure that the test materials in the test environment can fall into the partitioned table, the partitioned table index needs to be calculated in conjunction with the test pin in the test environment. That is, when the order pin is the test pin, the order will fall into the order partitioned table.

[0147] Based on the above scenario, the OrderMapper class is annotated with @ShardingTable(base="tbl_order", format="tbl_order_", strategy="orderShardingStrategy"), where "tbl_order" is the logical table name and "tbl_order_" is the prefix for order table partitioning. If the calculated partitioning index is 1, the actual table name is tbl_order_1, and the partitioning strategy is orderShardingStrategy. The above information can also be configured in the @ShardingField annotation, and @ShardingField will override the value in @ShardingTable.

[0148] In the insert method, the sharding field parameter is marked with @ShardingField(“id”). Since the order table is sharded based on the order id, it is marked with @ShardingField(“id”), where id is the order attribute id in OrderPO;

[0149] In the insert method, @ShardingAddition(value="pin", mapkey="pin") is used to mark additional information for the sharding table. Since the sharding phase uses the order ID number range for sharding, in order to ensure that the test materials in the test environment can fall into the sharding table, the sharding index calculation needs to be performed in conjunction with the test pin in the test environment. Therefore, the order pin attribute of the OrderPO needs to be passed to the sharding strategy manager orderShardingStrategy.

[0150] Further explanation of the additional information annotations:

[0151] Additional information annotations can be named @ShardingAddition in the program. They are mainly used to mark the parameters of the Mapper method that need to participate in the table sharding index calculation. Additional information is not a core table sharding parameter and is used for testing or volume splitting scenarios. The annotation information includes additional information attributes and additional information keys.

[0152] Preferably, the definition of @ShardingAddition is as follows:

[0153] / / Additional information annotation definition, applied to the parameter dimension of Mapper interface method.

[0154] / / i.e., PARAMETER dimension

[0155] @ShardingAddition{

[0156] / / Additional Information Attributes

[0157] String value()default"";

[0158] / / Additional information key

[0159] String mapkey()default"";

[0160] }

[0161] Setting the value: If the additional information parameter of the Mapper interface method is a simple data type, an array of simple data types, or a collection, then the value of @ShardingAddition does not need to be set; if the additional information parameter is a reference data type, an array of reference data types, or a collection, then the value of @ShardingAddition is assigned to the additional information property in the reference data type, and multi-level additional information property settings are supported, which is similar to OGNL expressions, and the usage is similar to setting the value of @ShardingField.

[0162] Mapkey setting: The attachment information is passed into the sub - table strategizer through a map structure, and the mapkey is set as the key of the map structure.

[0163] The Executor interceptor is used to elevate the processing of sub - table from reconstructing SQL statements to reconstructing method parameters, mainly including 6 components: metadata management, sub - table strategy management, sub - table parameter parsing, sub - table index calculation, sub - table parameter reconstruction, and sub - table result aggregation.

[0164] The metadata management, sub - table strategy management, sub - table parameter parsing, sub - table index calculation, sub - table parameter reconstruction, and sub - table result aggregation will be described one by one.

[0165] (1) Metadata management:

[0166] Metadata management is mainly used to parse and cache the sub - table related information of Mapper methods, avoiding multiple parsing. It mainly includes 4 mapping table information: method name -> method entity mapping table, method name -> method parameter name parser mapping table, method name -> sub - table information mapping table, and method name -> additional information mapping table. These mapping information are all used for the processing of sub - table logic in the interceptor.

[0167] The following will detail the 4 mapping tables from the storage structure and parsing process of each mapping table.

[0168] 1) Method name -> method entity mapping table

[0169] a. Storage structure

[0170] The method name is the name of the Mapper interface method, that is, the fully qualified class name + method name, and the method entity is the method entity object of the Mapper interface. For example, the mapping table information of the insert method in the example is:

[0171] Map<OrderMapper.insert, insertMethod instance>

[0172] b. Parsing process

[0173] The method entity parsing is mainly processed based on the statementId through reflection, and the method entity is cached after parsing to avoid multiple parsing.

[0174] The specific process of method entity parsing is as follows:

[0175] Step 1: The Executor interceptor intercepts the calls of query and update methods, and obtains the call information in the intercept method parameter Invocation of the interceptor.

[0176] It should be noted that the parser's method input parameter is: statementId; the Executor interceptor intercepts the Executor's query / update methods, and the interceptor's entry method is: Object intercept(Invocation invocation), where the Invocation information is as follows:

[0177] Object target: is an Executor object, including SimpleExecutor and ReuseExecutor objects;

[0178] Method method: The currently invoked query / update method;

[0179] Object[] args: The arguments of the currently invoked query / update method;

[0180] The parameters for the Executor's query and update methods are as follows:

[0181] MappedStatement ms: The MappedStatement corresponding to the current Mapper method, where id corresponds to the fully qualified class name + method name of the currently called method. Method entity resolution is mainly based on this id.

[0182] Object parameter: The parameter value of the current Mapper method (here, it is the parameter structure encapsulated by Mybatis, which can be a Map or a single object).

[0183] It should be noted that the parameters of the Executor's query and update methods are only those required for use in the interceptor in this invention.

[0184] Step 2: Get the args property of Invocation, and get the 0th parameter of the args array, which is MappedStatement.

[0185] Step 3: Parse the Mapper method based on the id attribute of MappedStatement, get the offset of the last "." in the id, and use this "." as a separator. The first half is the fully qualified class name, and the second half is the method name.

[0186] It should be noted that this part is retrieved from the method entity registry center based on the ID. If the ID is found, it is returned directly; otherwise, method parsing is performed.

[0187] Step 4: Obtain the corresponding Class object based on the fully qualified name, then obtain all method entities in the Class, filter out the corresponding method entities based on the method name, and store them in the method entity mapping table.

[0188] 2) Method name -> method parameter name resolver mapping table

[0189] a. Storage structure

[0190] The method name is the name of the Mapper interface method, which is the fully qualified class name plus the method name. The method parameter name resolver is mainly used to store the index of the Mapper interface method parameter and the mapping between the parameter name, i.e., Map.<paramIndex,paramName> For example, the mapping table information for the insert method in the example is:

[0191] Map <OrderMapper.insert,Map<0:”order”> >;

[0192] b. Analysis process

[0193] The method parameter name resolver primarily obtains the name from the following path: MappedStatement->Configuration->MapperRegistry->MapperProxyFactory->MapperMethod->MethodSignature->ParamNameResolver.

[0194] The process is handled through reflection, and the method parameter name resolver is cached after parsing to avoid multiple parsings.

[0195] The process of the method parameter name resolver is as follows:

[0196] Step 1: The Executor interceptor intercepts calls to the query and update methods and obtains the call information in the Invocation parameter of the interceptor method.

[0197] It should be noted that the parser's method parameters are: a MappedStatement object and a Method object; the path to obtain the method parameter name resolver ParamNameResovler is as follows:

[0198] MappedStatement->Configuration->MapperRegistry->MapperProxyFactory->MapperMethod->MethodSignature->ParamNameResolver.

[0199] Step 2: Get the args property of Invocation, and get the 0th parameter of the args array, which is MappedStatement.

[0200] Step 3: Obtain the configuration attribute of MappedStatement, which is of type Configuration.

[0201] Step 4: Obtain the mapperRegistry property of Configuration, which is of type MapperRegistry.

[0202] Step 5: Obtain the `knownMappers` property of `MapperRegistry`, which is of type `Map`.<class,MapperProxyFactory> .

[0203] Step 6: Obtain the MapperProxyFactory based on the current Mapper type.

[0204] Step 7: Obtain the `methodCache` property of `MapperProxyFactory`, which is of type `Map`.<Method,MapperMethod> .

[0205] Step 8: Obtain the MapperMethod based on the current Method entity.

[0206] Step 9: Obtain the method attribute of MapperMethod, which is of type MethodSignature.

[0207] Step 10: Obtain the paramNameResolver property of MethodSignature, which is of type ParamNameResolver. This object is the method parameter name resolver. Put this resolver into the method parameter name resolver mapping table.

[0208] It should be noted that the method parameter name resolver needs to be stored in the metadata registry to avoid duplicate parsing and performance degradation.

[0209] 3) Method Name -> Table Partitioning Information Mapping Table

[0210] a. Storage structure

[0211] The method name is the name of the Mapper interface method, which is the fully qualified class name + method name. The table sharding information is the method sharding information parsed based on the @ShardingField and @ShardingTable annotations, mainly encapsulated by ShardingFieldInfo, with the following structure:

[0212] ShardingFieldInfo extends ShardingTableInfo{

[0213] / / Should I use a separate table?

[0214] Boolean isShardingTable;

[0215] / / mapper method table partitioning parameter index

[0216] Integer shardingArgIndex;

[0217] / / Mapper method table partitioning attribute name

[0218] String shardingFieldName;

[0219] / / Whether the mapper method's table partitioning parameters are arrays

[0220] Boolean isShardingArgArray;

[0221] / / Whether the mapper method's table partitioning parameters are set

[0222] Boolean isShardingArgCollection;

[0223] / / Mapper method table partitioning parameter types

[0224] Class shardingArgType;

[0225] / / mapper method table partitioning parameter type generic

[0226] Type[]shardingArgParameterizedTypes;

[0227] / / Have the mapper method's table partitioning parameters been parsed?

[0228] Boolean isShardingArgParsed;

[0229] / / Whether mapper method's table attributes are arrays

[0230] Boolean isShardingFieldArray;

[0231] / / Whether mapper method table attributes are collections

[0232] Boolean isShardingFieldCollection;

[0233] / / mapper method table partitioning attribute type

[0234] Class shardingFieldType;

[0235] / / mapper method table partitioning attribute type generic

[0236] Type[]shardingFieldParameterizedTypes;

[0237] / / Have the mapper method's table partitioning attributes been parsed?

[0238] Boolean isShardingFieldParsed;

[0239] }

[0240] ShardingTableInfo{

[0241] / / Basic table name

[0242] String baseName;

[0243] / / Table prefix

[0244] String splitTablePrefix;

[0245] / / Table partitioning strategy

[0246] String strategy;

[0247] }

[0248] Note: The table sharding parameters of the mapper method are the parameters of the mapper method annotated with @ShardingField, such as the order parameter in the example above. The table sharding attributes of the mapper method are the attributes annotated in the table sharding parameters according to the value of @ShardingField, such as the id attribute in the order parameter in the example above.

[0249] For example, the table information mapped to the partitioned table information after parsing the insert method in the example is:

[0250] Map <OrderMapper.insert,{ShardingFieldInfo{

[0251] / / Should the table be split: Yes

[0252] isShardingTable:true,

[0253] / / Mapper method table partitioning parameter index: 0

[0254] shardingArgIndex:0,

[0255] / / mapper method table partitioning attribute name: id

[0256] shardingFieldName:"id",

[0257] / / Whether the mapper method's table partitioning parameter is an array: No

[0258] isShardingArgArray:false,

[0259] / / Whether the mapper method's table partitioning parameters are set: No

[0260] isShardingArgCollection:false,

[0261] / / Mapper method table partitioning parameter type: OrderPO

[0262] shardingArgType:OrderPO,

[0263] / / Mapper method table partitioning parameter type generic: no generic

[0264] shardingArgParameterizedTypes:null,

[0265] / / Whether the mapper method's table partitioning parameters have been parsed: true

[0266] isShardingArgParsed:true,

[0267] / / Whether the mapper method's table partitioning property is an array: false

[0268] isShardingFieldArray:false,

[0269] / / Whether the mapper method's table partitioning attributes are collected: No

[0270] isShardingFieldCollection:false,

[0271] / / mapper method table partitioning attribute type: Long

[0272] shardingFieldType:Long,

[0273] / / mapper method table partitioning attribute type generic: no generic

[0274] shardingFieldParameterizedTypes:null,

[0275] / / Have the mapper method's table partitioning attributes been parsed?: Yes

[0276] isShardingFieldParsed:true,

[0277] / / Basic table name: tbl_order

[0278] baseName:”tbl_order”,

[0279] / / Table prefix

[0280] splitTablePrefix:"tbl_order_",

[0281] / / Table partitioning strategy

[0282] strategy: "orderShardingStrategy";

[0283] }}>

[0284] b. Analysis process

[0285] The parsing of ShardingFieldInfo information is performed in two stages:

[0286] i. Parsing of table partitioning parameters in the Mapper method;

[0287] ii. Parsing the partitioning attribute of the partitioning parameter in the Mapper method;

[0288] The data is processed using parameter annotations and reflection mechanisms. After parsing, the table partitioning information is cached to avoid multiple parsings.

[0289] The detailed process for parsing table partitioning parameters is shown below:

[0290] Step 1: Obtain the method parameters using the getGenericParameterTypes() method of Method.

[0291] It should be noted that the parser's method input parameter is a Method object; the parsing of ShardingFieldInfo information is divided into two stages: one stage is the parsing of the Mapper method's sharding parameters, and the other stage is the parsing of the sharding attributes of the Mapper method's sharding parameters.

[0292] Step 2: Determine if the method parameters are empty; if not empty, proceed to step 3; if empty, proceed to step 8.

[0293] Step 3: Obtain parameter annotation information using the getParameterAnnotations() method of Method. The result is a two-dimensional array.

[0294] It should be noted that the format of the two-dimensional annotation array is as follows: [annotation array for parameter 0, annotation array for parameter 1, annotation array for parameter x].

[0295] Step 4: Traverse the two-dimensional array of parameter annotations to obtain the parameters marked with @ShardingField, which are the table sharding parameters.

[0296] Step 5: Determine if the table partitioning parameter is empty. If the table partitioning parameter is not empty, proceed to step 6. If the table partitioning parameter is empty, proceed to step 8.

[0297] Step 6: Set the isShardingTable, shardingArgIndex, and shardingFieldName of ShardingFieldInfo; set the base, splitTablePrefix, and strategy properties of ShardingFieldInfo based on the @ShardingField annotation. If they are empty, retrieve and set them based on the @ShardingTable annotation, and then proceed to Step 7.

[0298] Step 7: Set the properties of shardingArgType, shardingArgParameterizedTypes, isShardingArgArray, isShardingArgCollection, and isShardingArgParsed according to the type of the table sharding parameters.

[0299] It should be noted that if the table partitioning parameter is of type Class, then the following settings should be made:

[0300] shardingArgType: The type of the sharding parameter;

[0301] isShardingArgArray: The result returned by isArray() of the table-sharding parameter type;

[0302] isShardingArgCollection: The result returned by Collection.class.isAssignableFrom().

[0303] If the table partitioning parameter type is ParameterizedType, then configure it as follows:

[0304] shardingArgType: The result returned by getRawType() for the sharding parameter type;

[0305] shardingArgParameterizedTypes: The result returned by getActualTypeArguments() for shardingArgParameterizedTypes;

[0306] isShardingArgArray: The result returned by isArray() of the table-sharding parameter type RawType;

[0307] isShardingArgCollection: The result returned by Collection.class.isAssignableFrom().

[0308] If the table partitioning parameter type is GenericArrayType, then configure it as follows:

[0309] shardingArgType: The result returned by getGenericComponentType().getRawType() for the sharding parameter type;

[0310] shardingArgParameterizedTypes: The result returned by getGenericComponentType().getActualTypeArguments() for sharding parameter types;

[0311] isShardingArgArray: true;

[0312] isShardingArgCollection: false;

[0313] Other types do not currently support table partitioning.

[0314] Step 8: Set ShardingFieldInfo's isShardingTable to false and return.

[0315] The detailed process of parsing table partition attributes is shown below.

[0316] Step 1: Obtain the value of the shardingFieldName property of ShardingFieldInfo, such as abc or a.

[0317] It should be noted that the input parameters are ShardingFieldInfo and the shardingArg parameter; the shardingFieldInfo parsing is done in two stages: one stage is the parsing of the sharding parameters in the Mapper method, and the other stage is the parsing of the sharding attributes of the sharding parameters in the Mapper method.

[0318] Step 2: Obtain the offset of the last "." in shardingFieldName. Using this "." as a separator, the first half is the object name of the class where the sharding attribute is located, shardingObjectName, and the second half is the name of the sharding attribute within this object. Name it tmpShardingFieldName.

[0319] It should be noted that, taking abc as an example, shardingObjectName = ab, and tmpShardingFieldName = c.

[0320] Taking 'a' as an example, shardingObjectName = null, tmpShardingFieldName = a.

[0321] Step 3: Obtain the object containing the sharding field name tmpShardingFieldName based on the MetaObject and shardingObjectName of the sharding parameter shardingArg, and denote it as the sharding object shardingObject.

[0322] It should be noted that, taking "abc" as an example, shardingObjectName = ab, and tmpShardingFieldName = c. Based on the MetaObject of the sharding parameter shardingArg and ab, the object b can be obtained. Object b is the object containing the sharding attribute c, i.e., shardingObject.

[0323] Taking 'a' as an example, if objectName = null and tmpShardingFieldName = a, since objectName is empty, then shardingArg is the object containing the sharding attribute 'a', i.e., shardingObject.

[0324] Step 4: Obtain the sharding attribute Field object based on the class of the shardingObject and the sharding attribute tmpShardingFieldName.

[0325] It should be noted that this step is implemented based on the reflection mechanism.

[0326] Step 5: Obtain the table partitioning attribute type using TypeParameterResolve.resolveFieldType(Field,Type).

[0327] Step 6: Based on the table partitioning attribute type, set the properties of shardingFieldType, shardingFieldParameterizedTypes, isShardingFieldArray, isShardingFieldCollection, and isShardingFieldParsed.

[0328] It should be noted that if the table partitioning attribute type is Class, then the following settings should be made:

[0329] shardingFieldType: The type of the sharding field attribute;

[0330] isShardingFieldArray: The result returned by isArray() for the sharding field attribute type;

[0331] isShardingFieldCollection: Collection.class.isAssignableFrom() returns the result.

[0332] If the table partitioning attribute type is ParameterizedType, then set it as follows:

[0333] shardingFieldType: The result returned by getRawType() for the sharding field type;

[0334] shardingFieldParameterizedTypes: The result returned by getActualTypeArguments() for the sharding field parameterized type;

[0335] isShardingFieldArray: The result returned by isArray() of RawType, a table-sharding attribute type;

[0336] isShardingFieldCollection: Collection.class.isAssignableFrom() returns the result.

[0337] If the table partitioning attribute type is GenericArrayType, then set it as follows:

[0338] shardingFieldType: The result returned by getGenericComponentType().getRawType() for the sharding field type;

[0339] shardingFieldParameterizedTypes: The result returned by getGenericComponentType().getActualTypeArguments() for sharding field parameterized types;

[0340] isShardingFieldArray: true;

[0341] isShardingFieldCollection: false;

[0342] Other types do not currently support table partitioning.

[0343] 4) Method Name -> Additional Information Mapping Table

[0344] a. Storage structure

[0345] The method name is the name of the Mapper interface method, which is the fully qualified class name + method name. The additional information is the method sharding information parsed based on the @ShardingAddition annotation, mainly encapsulated by ShardingAdditionInfo, with the following structure:

[0346] ShardingAdditionInfo{

[0347] / / Additional information parameter index

[0348] private Integer paramIndex;

[0349] / / Additional attribute name

[0350] private String fieldName;

[0351] / / Additional attribute mapKey

[0352] private String keyName;

[0353] }

[0354] For example, the mapping table information parsed by the insert method in the example is:

[0355] Map <OrderMapper.insert:[{ShardingFieldInfo{

[0356] / / Additional information parameter index: 0

[0357] paramIndex:0,

[0358] / / Attached attribute name: "pin"

[0359] fieldName:”pin”,

[0360] / / Additional attribute mapKey: "pin"

[0361] keyName: "pin";

[0362] ]}}>

[0363] b. Analysis process

[0364] Processing is done through annotations, and the additional information is cached after parsing to avoid multiple parsings. The detailed process of parsing the additional information is as follows:

[0365] Step 1: Obtain the method parameters using the getGenericParameterTypes() method of Method.

[0366] It should be noted that the method parameter of the parser in this step is a Method object.

[0367] Step 2: Determine if the method parameter is empty; if it is not empty, proceed to step 3; if it is empty, proceed to step 6.

[0368] Step 3: Obtain parameter annotation information using the getParameterAnnotations() method of Method. The result is a two-dimensional array.

[0369] It should be noted that the format of the two-dimensional annotation array is as follows: [annotation array for parameter 0, annotation array for parameter 1, annotation array for parameter x].

[0370] Step 4: Traverse the two-dimensional array of parameter annotations and obtain the parameters marked with @ShardingAddition, which are the additional information parameters.

[0371] Step 5: Set the paramIndex of ShardingAdditionInfo; set the fieldName and keyName of ShardingAdditionInfo based on the @ShardingAddition annotation.

[0372] Step 6, End.

[0373] (II) Table partitioning strategy management

[0374] Table partitioning strategy management is primarily used to load and cache partitioning strategies for various business tables, and to calculate partitioning indexes for partitioning attribute values. It mainly includes the partitioning strategy interface definition and the partitioning strategy manager, which are described in detail below.

[0375] 1) Table partitioning strategy interface definition

[0376] The table partitioning strategy interface is used to define the specifications for table partitioning index calculation, and supports custom table partitioning logic for each business table.

[0377] When invoking a table partitioning strategy, the partitioning attribute value, additional partitioning information value, and Mapper method information of the currently invoked Mapper method are passed to the partitioning strategy for table partitioning index calculation. The returned result is a Map structure, where the key is the partitioning attribute value element and the value is its corresponding partitioning index.

[0378] The pseudocode for the table partitioning strategy interface is as follows:

[0379] ShardingTableStrategy{

[0380] / **

[0381] *Table partitioning

[0382] *

[0383] *@param shardingIds shardingIds Attribute values ​​for sharding tables

[0384] *@param shardingAdditionMap Additional information about sharding additionitionMap

[0385] *@param Information about the currently invoked method on the endpoint

[0386] *@return

[0387] /

[0388] Map<String,String> sharding(List <string>shardingIds,Map<String,Object> shardingAdditionMap,Endpoint endpoint);

[0389] }

[0390] Endpoint is defined as follows:

[0391] Endpoint{

[0392] / / mapper type

[0393] private Class mapperType;

[0394] / / mapper method entity

[0395] private Method method;

[0396] / / mapper method parameter values

[0397] Object[]params;

[0398] }

[0399] Among them, shardingIds is the sharding attribute value, which is mainly obtained by parsing the sharding information in the metadata management. For details, please refer to the sharding parameter parsing.

[0400] ShardingAdditionMap is a map of sharding-addition information values, which are mainly obtained from the sharding-addition information in metadata management. See the sharding parameter parsing for details.

[0401] The endpoint contains information about the currently invoked Mapper method, including the type of the currently invoked Mapper class, the Mapper method entity, and the method parameters.

[0402] 2) Table partitioning strategy manager

[0403] The partitioning strategy manager is used to load and cache partitioning strategies. It scans the implementation classes that implement the partitioning strategy interface and automatically registers them. When calculating the partitioning index in the interceptor, it obtains the partitioning strategy based on the partitioning strategy name configured in the Mapper method, thereby realizing the partitioning index calculation of the partitioning attribute value.

[0404] (III) Parsing of Table Parameters

[0405] The table partitioning parameter parsing section is used to extract table partitioning parameters, partitioning attribute values ​​used for calculating the table partitioning index, and additional table partitioning information values ​​from the current Mapper method. This section mainly includes table partitioning parameter parsing, partitioning attribute value parsing, and partitioning additional information value parsing.

[0406] 1) Parsing of table partitioning parameters

[0407] Table partitioning parameter parsing is used to parse the data from the Executor interceptor entry method.

[0408] The `Object intercept(Invocation invocation)` method parses the parameter array of the `Mapper` method from the `Invocation` parameter, and then parses the table partitioning parameters, table partitioning attribute values, and table partitioning additional information values ​​based on this parameter array.

[0409] Invocation is defined as follows:

[0410] Invocaton{

[0411] / / This refers to Executor objects, including SimpleExecutor and ReuseExecutor objects.

[0412] Object target;

[0413] / / For the query / update methods of the currently invoked Executor object

[0414] Method method;

[0415] / / Parameters for the query / update methods of the currently invoked Executor object

[0416] Object[]args;

[0417] }

[0418] The args parameter, which is the parameter of the query and update methods of the Executor object, is as follows:

[0419] MappedStatement ms is the MappedStatement corresponding to the current Mapper method;

[0420] The object parameter is the parameter value of the current Mapper method (here, it is the parameter structure encapsulated by Mybatis, which can be a Map or a single object). The table partitioning parameters, table partitioning attribute values, and additional table partitioning information values ​​of the Mapper method are parsed based on this parameter.

[0421] It should be noted that this invention only lists the parameters required for use in the interceptor.

[0422] The process for parsing table partitioning parameters is as follows:

[0423] Step 1: The Executor interceptor intercepts calls to the query and update methods; it retrieves the call information from the Invocation parameter of the interceptor method; it then extracts the parameter value (parameter) of the Mapper method from the call information (here, it's a parameter structure encapsulated by Mybatis, either a Map or a single object). This structure needs to be parsed into the actual parameter array of the Mapper method. The following steps parse the parameter to obtain the table partitioning parameters; the parameter structure is a Map.<paramName,paramObject> Or a single object.

[0424] It should be noted that the Executor interceptor intercepts the Executor's query / update methods. The interceptor's entry point method is Object intercept(Invocation invocation), where the Invocation information is as follows:

[0425] Object target: is an Executor object, including SimpleExecutor and ReuseExecutor objects;

[0426] Method method: The currently invoked query / update method;

[0427] Object[] args: The arguments of the currently invoked query / update method.

[0428] The parameters for the Executor's query and update methods are as follows:

[0429] MappedStatement ms: The MappedStatement corresponding to the current Mapper method;

[0430] Object parameter: The parameter value of the current Mapper method (here, it is the parameter structure encapsulated by Mybatis, which can be a Map or a single object).

[0431] The query and update methods of Executor only list the parameters that need to be used in the interceptor.

[0432] Step 2: Obtain the method parameter name resolver for the Mapper method from the method name -> method parameter name resolver mapping table. This table contains an array of names of the actual parameters of the Mapper method (stored in parameter order), denoted as names. The actual parameters of the Mapper method can be obtained from the parameter list through this array of names.

[0433] Step 3: Determine if the parameter structure is a Map. If it is, proceed to step 4; otherwise, proceed to step 5.

[0434] Step 4: If the parameter contains an element with the key "collection" and the parameter has only one element, wrap this element in an Object array and return it; if the parameter contains an element with the key "list" and the parameter has only one element, wrap this element in an Object array and return it; if the parameter contains an element with the key "array" and the parameter has only one element, wrap this element in an Object array and return it; if it does not contain any of the above elements, iterate through names and obtain the actual parameter array of the Mapper method from the parameter.

[0435] It should be noted that if the parameter contains an element with the key "collection" and the parameter has only one element, it means that the actual parameter of the Mapper method is a collection; if the parameter contains an element with the key "list" and the parameter has only one element, it means that the actual parameter of the Mapper method is a List; if the parameter contains an element with the key "array" and the parameter has only one element, it means that the actual parameter of the Mapper method is an array; if it does not contain any of the above elements, it means that the Mapper method contains multiple parameters.

[0436] It should be noted that step 6 is executed after step 4.

[0437] Step 5: Wrap the parameter in an Object array and return it.

[0438] It should be noted that step 6 is executed after step 5.

[0439] Step 6: Obtain the shardingArgIndex of the sharding information from the method name -> sharding information mapping table, and combine it with the parameter array returned in the previous step to obtain the sharding parameters.

[0440] 2) Parsing of table attribute values

[0441] Based on the table sharding parameters, the sharding attribute value is parsed according to the value of the shardingFieldName attribute in the shardingFieldInfo information, and used for subsequent sharding index calculation.

[0442] Based on the data types of the sharding parameters and the value of shardingFieldName (whether it is null), sharding scenarios mainly include the following four cases:

[0443] a. The table partitioning parameter is an array.

[0444] i. The table partitioning parameter is an array. If the shardingFieldName is empty, the array type must be Long[], long[], Integer[], int[], Short[], short[], Byte[], byte[], or String[] to support table partitioning.

[0445] ii. If the sharding parameter is an array, and shardingFieldName is not empty, then the sharding attribute type must be Long, long, Integer, int, Short, short, Byte, byte, or String to support sharding.

[0446] The parsing process for the table partitioning attribute value of the array in the above table partitioning scenario is as follows:

[0447] Step 1: Obtain the ShardingFieldInfo information of the Mapper method to determine whether table sharding is supported.

[0448] It should be noted that the main content of the obtained ShardingFieldInfo table partitioning information is as follows:

[0449] shardingArgClazz: Parameter type for table sharding;

[0450] shardingFieldClazz: sharding field attribute type;

[0451] hasShardingField: Whether the table sharding attribute exists;

[0452] shardingFieldName: The name of the sharding field attribute.

[0453] It should be noted that the table partitioning parameter is the parameter annotated with @ShardingField in the Mapper method. This process mainly explains the parsing process of the table partitioning attribute values ​​when the table partitioning parameter is an array.

[0454] When the table partitioning parameter is an array, table partitioning is supported only in the following two cases:

[0455] If `shardingFieldName` is empty, the array type must be `Long[]`, `long[]`, `Integer[]`, `int[]`, `Short[]`, `short[]`, `Byte[]`, `byte[]`, or `String[]` to support table partitioning; if `shardingFieldName` is not empty, the partitioning attribute type must be `Long`, `long`, `Integer`, `int`, `Short`, `short`, `Byte`, `byte`, or `String` to support table partitioning.

[0456] Step 2: Determine if the table partitioning attribute name does not exist and the table partitioning parameter type is a basic data type array (including String[]); if not, proceed to step 3; if yes, proceed to step 5.

[0457] Step 3: Determine if the table partitioning attribute name exists and if the table partitioning attribute type is a basic data type (including String); if yes, proceed to step 4; if no, proceed to step 6.

[0458] Step 4: Iterate through the MetaObject object of the sharding parameter to get each array element; pseudocode example: metaShardingArg.getValue("["+i+"]"); Get the sharding attribute value of each array element through the MetaObject object; pseudocode example: metaItem.getValue(shardingFieldName); Add the obtained sharding attribute value to a List. <string>Return to previous page to end.

[0459] It should be noted that the process of obtaining the attribute values ​​of the partitioned tables is mainly accomplished using Mybatis' MetaObject functionality.

[0460] Step 5: Convert the array-type table parameters into a string collection, then finish.

[0461] Step 6: Throw an exception, indicating that table partitioning is not supported, and the process ends.

[0462] b. The table partitioning parameter is List

[0463] i. The table partitioning parameter is List. If the shardingFieldName is empty, the generic type of List must be Long, Integer, Short, Byte, or String in order to support table partitioning.

[0464] ii. If the sharding parameter is a List, and shardingFieldName is not empty, then the sharding attribute type must be Long, long, Integer, int, Short, short, Byte, byte, or String to support sharding.

[0465] When the above table partitioning scenario involves a List, the corresponding table partitioning attribute value parsing process is as follows:

[0466] Step 1: Obtain the ShardingFieldInfo information of the Mapper method to determine whether table sharding is supported.

[0467] It should be noted that the main content of the obtained ShardingFieldInfo table partitioning information is as follows:

[0468] shardingArgParameterizedTypes: sharding parameter generics;

[0469] shardingFieldClazz: sharding field attribute type;

[0470] hasShardingField: Whether the table sharding attribute exists;

[0471] shardingFieldName: The name of the sharding field attribute.

[0472] It should be noted that the table partitioning parameter is the parameter annotated with @ShardingField in the Mapper method. This process mainly explains the parsing process of the table partitioning attribute values ​​when the table partitioning parameter is a List.

[0473] When the table partitioning parameter is a List, table partitioning is supported only in the following two cases:

[0474] If shardingFieldName is empty, the generic type of the List must be Long, Integer, Short, Byte, or String to support table partitioning; if shardingFieldName is not empty, the type of the partitioning attribute must be Long, long, Integer, int, Short, short, Byte, byte, or String to support table partitioning.

[0475] Step 2: Determine if the table partitioning attribute name does not exist and the table partitioning parameter generic type is a basic data type (including String); if not, proceed to step 3; if yes, proceed to step 5.

[0476] Step 3: Determine if the table partitioning attribute name exists and if the table partitioning attribute type is a basic data type (including String); if yes, proceed to step 4; if no, proceed to step 6.

[0477] Step 4: Loop through the List to get each collection element. For each collection element's MetaObject, retrieve its sharding attribute value, for example: `metaItem.getValue(shardingFieldName)`. Add the retrieved sharding attribute value to the List. <string>Return to previous page to end.

[0478] It should be noted that the process of obtaining the attribute values ​​of the partitioned tables is mainly accomplished using Mybatis' MetaObject functionality.

[0479] Step 5: Convert the List type sub-table parameter into a string collection and return it to complete the process.

[0480] Step 6: Throw an exception, indicating that table partitioning is not supported, and the process ends.

[0481] c. The table partitioning parameter is Set

[0482] i. The table partitioning parameter is a Set. If the shardingFieldName is empty, the generic type of the Set must be Long, Integer, Short, Byte, or String in order to support table partitioning.

[0483] ii. If the sharding parameter is a Set, and shardingFieldName is not empty, then the sharding attribute type must be Long, long, Integer, int, Short, short, Byte, byte, or String to support sharding.

[0484] The parsing process for table partitioning attribute values ​​in the above scenario where the partitioning is a Set is as follows:

[0485] Step 1: Obtain the ShardingFieldInfo information of the Mapper method to determine whether table sharding is supported.

[0486] It should be noted that the main content of the obtained ShardingFieldInfo table partitioning information is as follows:

[0487] shardingArgParameterizedTypes: sharding parameter generics;

[0488] shardingFieldClazz: sharding field attribute type;

[0489] hasShardingField: Whether the table sharding attribute exists;

[0490] shardingFieldName: The name of the sharding field attribute.

[0491] It should be noted that the table partitioning parameter is the parameter annotated with @ShardingField in the Mapper method. This process mainly explains the parsing process of the table partitioning attribute value when the table partitioning parameter is a Set.

[0492] When the partitioning parameter is a Set, partitioning is supported only in the following two cases:

[0493] If shardingFieldName is empty, the generic type of the Set must be Long, Integer, Short, Byte, or String to support table partitioning; if shardingFieldName is not empty, the type of the partitioning attribute must be Long, long, Integer, int, Short, short, Byte, byte, or String to support table partitioning.

[0494] Step 2: Determine if the table partitioning attribute name does not exist and the table partitioning parameter generic type is a basic data type (including String); if not, proceed to step 3; if yes, proceed to step 5.

[0495] Step 3: Determine if the table partitioning attribute name exists and if the table partitioning attribute type is a basic data type (including String); if yes, proceed to step 4; if no, proceed to step 6.

[0496] Step 4: Loop through the Set to get each collection element. For each collection element's MetaObject, retrieve its sharding attribute value, as shown in the pseudocode: `metaItem.getValue(shardingFieldName)`. Add the retrieved sharding attribute value to the List. <string>,Finish.

[0497] The process of retrieving table attribute values ​​is mainly accomplished using Mybatis' MetaObject functionality.

[0498] Step 5: Convert the Set type table partitioning parameters into a string collection and return it to complete the process.

[0499] Step 6: Throw an exception, indicating that table partitioning is not supported, and the process ends.

[0500] d. The table partitioning parameter is a single object.

[0501] i. The sharding parameter is a single object. If shardingFieldName is empty, the type of the single object must be Long, long, Integer, int, Short, short, Byte, byte, or String in order to support sharding.

[0502] ii. The sharding parameter is a single object. If shardingFieldName is not empty, the sharding attribute must be an array, List, Set, or single object of a basic type (including String) to support sharding.

[0503] The table partitioning attribute value parsing process for a single object in the above table partitioning scenario is as follows:

[0504] Step 1: Obtain the ShardingFieldInfo information of the Mapper method to determine whether table sharding is supported.

[0505] It should be noted that the main content of the obtained ShardingFieldInfo table partitioning information is as follows:

[0506] shardingArgClazz: Parameter type for table sharding;

[0507] isShardingFieldArray: Whether the sharding field attributes are an array;

[0508] isShardingFieldCollection: Whether the sharding field attribute is a collection;

[0509] shardingFieldClazz: sharding field attribute type;

[0510] shardingFieldParameterizedTypes: The generic type of the sharding field attribute;

[0511] hasShardingField: Whether the table sharding attribute exists.

[0512] It should be noted that the table partitioning parameter is the parameter annotated with @ShardingField in the Mapper method. This process mainly explains the parsing process of the table partitioning attribute value when the table partitioning parameter is a single object.

[0513] When the partitioning parameter is a single object, partitioning is supported only in the following two cases:

[0514] If shardingFieldName is empty, the type of a single object must be Long, long, Integer, int, Short, short, Byte, byte, or String to support table partitioning; if shardingFieldName is not empty, the partitioning attribute must be an array, List, Set, or a single object of a basic type (including String) to support table partitioning.

[0515] Step 2: Determine if the table partitioning attribute name does not exist and the table partitioning parameter generic type is a basic data type (including String); if not, proceed to step 3; if yes, proceed to step 5.

[0516] Step 3: Determine if the table attribute name exists. If yes, proceed to step 4; otherwise, proceed to step 6.

[0517] Step 4: If the table partitioning attribute type is an array, and the array type is a primitive data type array (including String[]), convert this array to a string collection and return it; if the table partitioning attribute type is a List, and the generic type is a primitive data type (including String), convert this List to a string collection and return it; if the table partitioning attribute type is a Set, and the generic type is a primitive data type (including String), convert the Set to a string collection and return it; if the table partitioning attribute type is a single object, and the type is a primitive data type (including String), convert the table partitioning attribute to a string collection and return it. End.

[0518] Step 5: Convert the table partitioning parameters into a string collection, then finish.

[0519] Step 6: Throw an exception, indicating that table partitioning is not supported, and the process ends.

[0520] 3) Parsing additional information values ​​from table partitions

[0521] Based on the parameter array of the Mapper method (see Sharding Parameter Parsing for details), the shardingAdditionInfo value is parsed for subsequent sharding index calculation. The shardingAdditionInfo value parsing process is as follows:

[0522] Step 1: Parse the actual parameter array of the Mapper method and the additional information on the table partitioning.

[0523] It should be noted that the actual parameter array parsing process of the Mapper method is described in the table partitioning parameter parsing process; the additional information of the table partitioning is maintained by the method name -> additional information mapping table.

[0524] Step 2: Loop through the list of additional information. Based on paramIndex, retrieve the additional information parameter from the parameter array. Use the MetaObject object of the additional information parameter and the fieldName of the additional information to get the additional information value. Pseudocode: metaObject.getValue(fieldName); Get the keyName of the additional information and store the keyName and the additional information value in a Map and return it.

[0525] It should be noted that the process of obtaining additional information is mainly accomplished using Mybatis' MetaObject functionality.

[0526] (iv) Calculation of table indexes

[0527] The calculation of table partitioning indexes is mainly based on the table partitioning strategy, which performs table partitioning index calculation and heaping processing on the attribute values ​​of the partitioned tables.

[0528] 1) Calculation of table partition index

[0529] The table sharding index calculation is primarily based on the table sharding strategy. It calculates the table sharding index corresponding to each attribute value based on the parsed table sharding attribute values, additional table sharding information values, and the currently invoked Mapper method information. The returned result is a Map<single table sharding attribute value, table sharding index>. See the table sharding strategy management for the table sharding strategy interface definition.

[0530] The implementation of the table partitioning strategy for each business table is left to the respective systems, and can be implemented using MurmurHash or perturbation functions, etc., which will not be elaborated here.

[0531] 2) Stacking processing

[0532] The heapification process mainly involves heapification of the Map<single table attribute value, table index> returned by the calculation of the table index. The table attribute values ​​are heapified according to the table index dimension, and the result is Map<table index, List<single table attribute value>>.

[0533] The specific process for calculating the table partition index is as follows:

[0534] Step 1: Based on the partitioning strategy name in the partitioning information, retrieve the partitioning strategy from the partitioning strategy manager.

[0535] It should be noted that the table partitioning information is obtained from the method name -> table partitioning information mapping table; the table partitioning strategy is obtained from the table partitioning strategy manager.

[0536] Step 2: Invoke the table partitioning strategy (partitioning attribute value, additional partitioning information value, and information of the currently invoked Mapper method) to obtain the partitioning index, with the structure being Map<single partitioning attribute value, partitioning index>.

[0537] Step 3: Traverse the Map<single table attribute value, table index>, and group table attribute values ​​with the same table index together, with the structure being Map<table index, List<single table attribute value>>.

[0538] (V) Reconstructing Table Parameters

[0539] The reconstruction of table partitioning parameters is mainly based on the heap results calculated from the table partitioning index, i.e., Map<table partitioning index, List<single table attribute value>>, to split and reconstruct table partitioning parameters, especially for table partitioning parameters of collection and array types.

[0540] Compared to parsing the table attribute values ​​from the table parameters mentioned above, table parameter reconstruction can be understood as the reverse engineering of table attribute value parsing, reconstructing the table parameters based on the table attribute values.

[0541] Similarly, considering the data types of the sharding parameters and the value of shardingFieldName (whether it is empty), the reconstruction of sharding parameters mainly includes the following four cases:

[0542] 1) The table partitioning parameter is an array

[0543] i. If shardingFieldName is empty and the array type is Long[], long[], Integer[], int[], Short[], short[], Byte[], byte[], or String[], then directly split the table parameters;

[0544] ii. If shardingFieldName is not empty and the sharding attribute type is Long, long, Integer, int, Short, short, Byte, byte, or String, then the sharding parameters are split according to the sharding attribute value.

[0545] The process for refactoring the table partitioning parameters when the partitioning parameters are arrays in the above scenarios is as follows:

[0546] Step 1: Obtain the ShardingFieldInfo information of the Mapper method and perform sharding parameter splitting.

[0547] It should be noted that the main content of the obtained ShardingFieldInfo table partitioning information is as follows:

[0548] shardingArgClazz: Parameter type for table sharding;

[0549] shardingFieldClazz: sharding field attribute type;

[0550] hasShardingField: Whether the table sharding attribute exists;

[0551] shardingFieldName: The name of the sharding field attribute.

[0552] It should be noted that the result of the table attribute values ​​calculated based on the table partitioning index is a heap, namely Map<table partitioning index, List<single table attribute value>>, which is used to split the table partitioning parameters in a loop.

[0553] The table partitioning parameter is the parameter annotated with @ShardingField in the Mapper method. This process mainly explains the process of splitting the table partitioning parameter when the table partitioning parameter is an array.

[0554] When the sharding parameter is an array, the sharding parameter is split in two cases: if shardingFieldName is empty and the array type is Long[], long[], Integer[], int[], Short[], short[], Byte[], byte[], or String[], then the sharding parameter is split directly; if shardingFieldName is not empty and the sharding attribute type is Long, long, Integer, int, Short, short, Byte, byte, or String, then the sharding parameter is split according to the sharding attribute value.

[0555] Step 2: Determine if the table partitioning attribute name does not exist and the table partitioning parameter type is a basic data type array (including String[]); if not, proceed to step 3; if yes, proceed to step 5.

[0556] Step 3: Determine if the table partitioning attribute name exists and if the table partitioning attribute type is a basic data type (including String); if yes, proceed to step 4; if no, proceed to step 6.

[0557] Step 4: Iterate through the MetaObject object of the sharding parameter to get each array element, pseudocode such as: metaShardingArg.getValue("["+i+"]"); Get the sharding attribute value of each array element through the MetaObject object, pseudocode such as: metaItem.getValue(shardingFieldName); Split the sharding parameter array according to the heap result List<single sharding attribute value> and the sharding attribute value.

[0558] It should be noted that the process of obtaining the attribute values ​​of the partitioned tables is mainly accomplished using Mybatis' MetaObject functionality.

[0559] Step 5: Split the array-type partitioning parameters according to the heaping result List<single partitioning attribute value>, and then finish.

[0560] Step 6: Throw an exception, indicating that table partitioning is not supported, and the process ends.

[0561] 2) The table partitioning parameter is List

[0562] i. If the table partitioning parameter is a List, and the shardingFieldName is empty, and the generic type of the List is Long, Integer, Short, Byte, or String, then the table partitioning parameter is directly split.

[0563] ii. If the sharding parameter is a List, and the shardingFieldName is not empty, and the sharding attribute type must be Long, long, Integer, int, Short, short, Byte, byte, or String, then the sharding parameter will be split according to the sharding attribute value.

[0564] The process for refactoring the table partitioning parameters when the partitioning parameter is a List in the above scenario is as follows:

[0565] Step 1: Obtain the ShardingFieldInfo information of the Mapper method and perform sharding parameter splitting.

[0566] It should be noted that the main content of the obtained ShardingFieldInfo table partitioning information is as follows:

[0567] shardingArgParameterizedTypes: sharding parameter generics;

[0568] shardingFieldClazz: sharding field attribute type;

[0569] hasShardingField: Whether the table sharding attribute exists;

[0570] shardingFieldName: The name of the sharding field attribute.

[0571] It should be noted that the result of stacking the table attribute values ​​is calculated based on the table index, i.e., Map<table index, List<single table attribute value>>, and the table parameter is split in a loop.

[0572] The table partitioning parameter is the parameter annotated with @ShardingField in the Mapper method. This process mainly explains the process of splitting the table partitioning parameter when the table partitioning parameter is a List.

[0573] When the sharding parameter is a List, the sharding parameter is split in two cases: if shardingFieldName is empty and the generic type of List is Long, Integer, Short, Byte, or String, then the sharding parameter is split directly; if shardingFieldName is not empty and the sharding attribute type must be Long, long, Integer, int, Short, short, Byte, byte, or String, then the sharding parameter is split according to the sharding attribute value.

[0574] Step 2: Determine if the table partitioning attribute name does not exist and the table partitioning parameter generic type is a basic data type (including String); if not, proceed to step 3; if yes, proceed to step 5.

[0575] Step 3: Determine if the table partitioning attribute name exists and if the table partitioning attribute type is a basic data type (including String); if yes, proceed to step 4; if no, proceed to step 6.

[0576] Step 4: Loop through the List to get each collection element. Use the MetaObject object of each collection element to get its sharding attribute value. Pseudocode: metaItem.getValue(shardingFieldName); Based on the heap result List<single sharding attribute value> and the sharding attribute value, split the sharding parameter List, and then end.

[0577] It should be noted that the process of obtaining the attribute values ​​of the partitioned tables is mainly accomplished using Mybatis' MetaObject functionality.

[0578] Step 5: Split the List type partitioning parameters according to the heaping result List<single partitioning attribute value>, and then finish.

[0579] Step 6: Throw an exception, indicating that table partitioning is not supported, and the process ends.

[0580] 3) The table partitioning parameter is a Set

[0581] i. If the sharding parameter is a Set, and the shardingFieldName is empty, and the generic type of the Set is Long, Integer, Short, Byte, or String, then the sharding parameter is directly split.

[0582] ii. If the sharding parameter is a Set, and the shardingFieldName is not empty, and the sharding attribute type must be Long, long, Integer, int, Short, short, Byte, byte, or String, then the sharding parameter will be split according to the sharding attribute value.

[0583] The process for refactoring the table partitioning parameters when the partitioning parameters are Sets in the above scenarios is as follows:

[0584] Step 1: Obtain the ShardingFieldInfo information of the Mapper method and perform sharding parameter splitting.

[0585] It should be noted that the main content of the obtained ShardingFieldInfo table partitioning information is as follows:

[0586] shardingArgParameterizedTypes: sharding parameter generics;

[0587] shardingFieldClazz: sharding field attribute type;

[0588] hasShardingField: Whether the table sharding attribute exists;

[0589] shardingFieldName: The name of the sharding field attribute.

[0590] It should be noted that the result of the heap of the table attribute values ​​calculated based on the table index is a Map<table index, List<single table attribute value>>, which is used to split the table parameters in a loop. The table parameters are the parameters annotated with @ShardingField in the Mapper method. This process mainly describes the splitting process of the table parameters when the table parameters are Sets.

[0591] When the table partitioning parameter is a Set, the table partitioning parameter will be split in the following two cases:

[0592] If shardingFieldName is empty and the generic type of the Set is Long, Integer, Short, Byte, or String, then the sharding parameters are directly split; if shardingFieldName is not empty and the sharding attribute type must be Long, long, Integer, int, Short, short, Byte, byte, or String, then the sharding parameters are split according to the sharding attribute value.

[0593] Step 2: Determine if the table partitioning attribute name does not exist and the table partitioning parameter generic type is a basic data type (including String); if not, proceed to step 3; if yes, proceed to step 5.

[0594] Step 3: Determine if the table partitioning attribute name exists and if the table partitioning attribute type is a basic data type (including String); if yes, proceed to step 4; if no, proceed to step 6.

[0595] Step 4: Loop through the Set to get each collection element. Use the MetaObject object of each collection element to get its sharding attribute value. Pseudocode: metaItem.getValue(shardingFieldName); Based on the heap result List<single sharding attribute value> and the sharding attribute value, split the sharding parameter Set, and then end.

[0596] It should be noted that the process of obtaining the attribute values ​​of the partitioned tables is mainly accomplished using Mybatis' MetaObject functionality.

[0597] Step 5: Split the Set-type partitioning parameters according to the heaping result List<single partitioning attribute value>, and then finish.

[0598] Step 6: Throw an exception, indicating that table partitioning is not supported, and the process ends.

[0599] 4) The table partitioning parameter is a single object.

[0600] i. If shardingFieldName is empty and the type of a single object is Long, long, Integer, int, Short, short, Byte, byte, or String, then the sharding parameter is returned directly;

[0601] ii. If shardingFieldName is not empty, and the sharding attribute is an array, List, Set, or single object of a basic type (including String), then the sharding parameters are split and reconstructed based on the sharding attribute value.

[0602] The process for refactoring the table partitioning parameters when the partitioning parameter is a single object in the above scenario is as follows:

[0603] Step 1: Obtain the ShardingFieldInfo information of the Mapper method, and perform sharding parameter splitting and reconstruction.

[0604] It should be noted that the main content of the obtained ShardingFieldInfo table partitioning information is as follows:

[0605] shardingArgClazz: Parameter type for table sharding;

[0606] isShardingFieldArray: Whether the sharding field attributes are an array;

[0607] isShardingFieldCollection: Whether the sharding field attribute is a collection;

[0608] shardingFieldClazz: sharding field attribute type;

[0609] shardingFieldParameterizedTypes: The generic type of the sharding field attribute;

[0610] hasShardingField: Whether the table sharding attribute exists.

[0611] Based on the heap results of the sharded attribute values ​​calculated from the sharded index, i.e., Map<sharded index, List<single sharded attribute value>>, the sharded parameter is split and reconstructed in a loop. The sharded parameter is the parameter annotated with @ShardingField in the Mapper method. This process mainly explains the sharded parameter splitting and reconstruction for the following two cases when the sharded parameter is a single object:

[0612] If shardingFieldName is empty and the type of the single object is Long, long, Integer, int, Short, short, Byte, byte, or String, then the sharding parameter is returned directly; if shardingFieldName is not empty and the sharding attribute is an array, List, Set, or single object of a basic type (including String), then the sharding parameter is split and reconstructed based on the sharding attribute value.

[0613] Step 2: Determine if the table partitioning attribute name does not exist and the table partitioning parameter generic type is a basic data type (including String); if not, proceed to step 3; if yes, proceed to step 7.

[0614] Step 3: Determine if the table attribute name exists. If yes, proceed to step 4; otherwise, proceed to step 6.

[0615] Step 4: For table-sharding attribute types that are arrays, and the array type is a primitive type array (including String[]), split the table-sharding attribute array according to the heapification result List<single table-sharding attribute value>; for table-sharding attribute types that are List, and the generic type is a primitive data type (including String), split the table-sharding attribute List according to the heapification result List<single table-sharding attribute value>; for table-sharding attribute types that are Set, and the generic type is a primitive data type (including String), split the table-sharding attribute Set according to the heapification result List<single table-sharding attribute value>; for table-sharding attribute types that are single objects, and the type is a primitive data type (including String), no splitting is required; the new table-sharding attribute value is newShardingFieldObject.

[0616] It should be noted that after performing step 4, proceed to step 5.

[0617] Step 5: Copy a new sharding parameter `newShardingArg` and refactor it; set its new sharding attribute value using the new sharding parameter's MetaObject object, for example: `metaNewShardingArg.setValue(shardingFieldName, newShardingFieldObject)`; retrieve the new sharding parameter from the new sharding parameter's MetaObject, for example: `metaNewShardingArg.getOriginalObject()`, and you're done.

[0618] Step 6: Throw an exception, indicating that table partitioning is not supported, and the process ends.

[0619] Step 7: Directly return the table partitioning parameters and end.

[0620] (vi) Aggregation of results from separate tables

[0621] The aggregation of table partitioning results mainly involves aggregating the database access results after the table partitioning parameters have been reconstructed.

[0622] As mentioned earlier, the table partitioning index calculation is used to calculate the table partitioning index and to heap the Map<single table partitioning attribute value, table partitioning index> returned by the table partitioning strategy. The heaping result is Map<table partitioning index, List<single table partitioning attribute value>>.

[0623] The table partitioning parameters are reconstructed by iterating through the resulting Map<table partitioning index, List<single table attribute value>> to split and reconstruct the table partitioning parameters.

[0624] The table sharding results are aggregated. Based on the sharding parameters of each heap split and reconstructed table (these parameters are the actual parameters of the Mapper method), the parameters of the Mybatis-encapsulated Mapper method (structure is Map or a single object) are reset. Then, the Invocation's process method is called to perform subsequent process processing, that is, to obtain the query or update results of the new sharding parameters. At the same time, the sharding index of each heap is written to ThreadLocal for SQL replacement by the StatementHandler interceptor.

[0625] The processing flow for aggregating table partitioning results is as follows:

[0626] Step 1: Define an aggregate collection `collectList`, which is used to summarize query results; define an aggregate collection `collectAffectedRows`, which is used to summarize update results.

[0627] Step 2: Obtain the sharding parameters and reconstruct the new sharding parameters newShardingArg. If the parameter type of the Mapper method is Map (here, the parameter structure encapsulated by Mybatis), then reset the sharding parameters. The pseudocode is as follows: metaParamObject.setValue(shardingArgName,newShardingArg); if it is not Map, then directly replace the parameters. The pseudocode is as follows: invocationArgs[1] = newShardingArg.

[0628] It should be noted that the aggregation of table partitioning results is used to iterate through the parameters of each new partition. This process mainly describes the processing logic of the loop body, which mainly includes the following:

[0629] Based on the partitioning and reconstruction parameters of each heap (these parameters are the actual parameters of the Mapper method), the parameters of the Mapper method encapsulated by Mybatis are reset (the structure is a Map or a single object). Then, the process method of Invocation is called to perform subsequent process processing, that is, to obtain the query or update results of the new partitioning parameters; the partitioning index of each heap is written to ThreadLocal for SQL replacement by the StatementHandler interceptor.

[0630] Step 3: Set the table partitioning context (stored in ThreadLocal), setting whether to partition the table and the partitioned index data, which is used for SQL replacement by the StatementHandler interceptor.

[0631] Step 4: Is a query operation required? If yes, proceed to step 5; otherwise, proceed to step 6.

[0632] Step 5: Call the `proceed` method of `Invocation` to store the query results in `collectionList`, and then execute step 7.

[0633] Step 6: Call the `proceed` method of `Invocation` to accumulate the update results into `collectAffectedRows`, and then execute Step 7.

[0634] Step 7: Clear the partition context, proceed with the next new partition parameter query or update process, and end.

[0635] The StatementHandler interceptor is explained below. It mainly defines a logical table name converter, which is used to replace the logical table name of the SQL with the actual table name.

[0636] The StatementHandler interceptor primarily intercepts the StatementHandler's prepare method to modify table names in SQL statements. Its processing flow is as follows:

[0637] Step 1: Obtain whether the table is partitioned and the partition index data from the partition context (stored in ThreadLocal).

[0638] It should be noted that the StatementHandler interceptor intercepts the StatementHandler's prepare method. The interceptor's entry method is Object intercept(Invocation invocation), where the Invocation information is as follows:

[0639] Object target: is a StatementHandler object, including objects such as RoutingStatementHandler;

[0640] Method method: The currently invoked prepare method;

[0641] Object[] args: The arguments to the currently invoked prepare method.

[0642] It should be noted that the table partitioning context is stored during the table partitioning result aggregation stage, which stores whether the table is partitioned and the table partitioning index data.

[0643] Step 2: Determine whether the table is split and the value is empty or not split; if not, proceed to step 3; if yes, proceed to step 7.

[0644] Step 3: Since the StatementHandler is proxied, the MetaObject of the actual StatementHandler object is obtained through recursion layer by layer via MetaObject, i.e., metaRoutingStatementHandler. The pseudocode is as follows:

[0645] Recursively retrieve the value of `metaStatementHandler.getValue("h")`.

[0646] Recursively retrieve the value of `metaStatementHandler.getValue("target")`.

[0647] It should be noted that after performing step 3, proceed to step 4.

[0648] Step 4: Obtain the MappedStatement object based on the delegate.mappedStatement property of metaRoutingStatementHandler.

[0649] Step 5: Retrieve the sharding information from the method name -> sharding information mapping table based on the MappedStatement's id. Obtain the base table name (baseName) and sharding prefix (splitTablePrefix) from the sharding information. Obtain the SQL statement based on the delegate.boundSql.sql property of metaRoutingStatementHandler. Replace the base table name (i.e., logical table name) in the SQL statement with the sharding prefix + sharding index, i.e., the actual table name, denoted as shardingSql. Reset the delegate.boundSql.sql property of metaRoutingStatementHandler to shardingSql.

[0650] Step 6: Invocation.proceed is called, the process continues, and then ends.

[0651] Step 7: Without performing logical table name replacement, call invocation.proceed, and the process continues until it ends.

[0652] This invention handles table partitioning logic uniformly within the interceptor, resulting in minimal intrusion into business logic. The implementation is decoupled from business logic, leading to clear business code logic. It eliminates the need for specific table partitioning parameters of particular names or types, enabling rapid support for modifying existing system table partitioning and supporting batch operations.

[0653] and Figure 1 Correspondingly, embodiments of the present invention also provide a data processing apparatus, which is used to support Figure 1 The specific implementation of the method shown is illustrated in the following diagram of the device. Figure 6 As shown, the specific explanation is as follows:

[0654] Interception unit 501 is used to intercept the currently called database access layer method through a preset first interceptor;

[0655] The parsing unit 502 is used to parse the parameter annotation information of the database access layer method and obtain the metadata of the database access layer method. The metadata includes a method entity mapping table, a method parameter name parser mapping table, a table partitioning information mapping table, and an additional information mapping table.

[0656] The acquisition unit 503 is used to acquire the table partitioning parameters, table partitioning attribute values, and table partitioning additional information values ​​from the call information of the database access layer method based on the metadata of the database access layer method.

[0657] The calculation unit 504 is used to obtain the table partitioning strategy based on the table partitioning strategy name of the database access layer method. In the table partitioning strategy, the table partitioning attribute value is indexed based on the table partitioning attribute value, the table partitioning additional information value and the database access layer method information to obtain the table partitioning index result of the table partitioning attribute value.

[0658] The reconstruction unit 505 is used to reconstruct the table parameters based on the table index result, to obtain each reconstructed table parameter and the table index of each reconstructed table parameter, and to save the table index of each reconstructed table parameter to a preset table context.

[0659] The replacement unit 506 is used to replace the logical table name of the Structured Query Language (SQL) statement corresponding to each of the reconstructed table parameters with the actual table name based on each of the table indexes in the table partitioning context through a preset second interceptor, so that each of the reconstructed table parameters can access the database based on the actual table name of the SQL statement and obtain the database access result of each of the reconstructed table parameters.

[0660] Aggregation unit 507 is used to aggregate the database access results of each reconstructed table parameter to obtain the final call result of the database access layer method.

[0661] In the apparatus provided by this invention, a first interceptor intercepts the currently invoked database access layer method, parses the parameter annotation information of the database access layer method to obtain its metadata, and, based on the metadata, retrieves the sharding parameters, sharding attribute values, and sharding additional information values ​​from the method's invocation information. The sharding strategy is then obtained based on the sharding strategy name of the database access layer method. Within the sharding strategy, the sharding attribute values ​​are indexed and calculated based on the sharding attribute values, sharding additional information values, and the database access layer method information to obtain the sharding attribute values. The system obtains the table partitioning index results; based on the table partitioning index results and table attribute values, the table partitioning parameters are reconstructed to obtain each reconstructed table partitioning parameter and its corresponding table partitioning index. The table partitioning index of each reconstructed table partitioning parameter is saved to the table partitioning context. This allows the second interceptor to replace the logical table name in the SQL statement for each reconstructed table partitioning parameter with the actual table name, enabling each reconstructed table partitioning parameter to access the database based on the actual table name in the SQL statement, thus obtaining the database access result for each reconstructed table partitioning parameter. The database access results are then aggregated to obtain the final call result of the database access layer method. This invention achieves table partitioning transformation without modifying the system, thereby improving the efficiency of data partitioning.

[0662] In another embodiment of the present invention, the parsing unit of the device includes:

[0663] The first acquisition subunit is used by the first interceptor to acquire the first parameter in the parameter array attribute of the call information, and to acquire the underlying encapsulation object based on the first parameter;

[0664] The parsing subunit is used to parse the identity attributes of the underlying encapsulated object and obtain the fully qualified class name and method name;

[0665] The second acquisition subunit is used to acquire the bytecode object corresponding to the fully qualified class name, determine the method entity in the bytecode object corresponding to the method name, and cache the determined method entity to obtain a method entity mapping table.

[0666] The caching subunit is used to obtain the method parameter name resolver based on the underlying encapsulated object, and cache the method parameter name resolver to obtain a method parameter name resolver mapping table;

[0667] The third acquisition subunit is used to acquire the table partitioning parameter annotation information of the database access layer method from the parameter annotation information, parse the table partitioning parameters and the table partitioning attributes of the database access layer method based on the table partitioning parameter annotation information, obtain the table partitioning information, cache the table partitioning information, and obtain the table partitioning information mapping table.

[0668] The fourth acquisition subunit is used to obtain the table partitioning additional parameter annotation information of the database access layer method from the parameter annotation information, parse the table partitioning additional parameters of the database access layer method based on the table partitioning additional parameter annotation information to obtain the table partitioning additional information, and cache the table partitioning additional information to obtain an additional information mapping table.

[0669] In another embodiment of the present invention, the acquisition unit of the device includes:

[0670] The fifth acquisition subunit is used to acquire the second parameter in the parameter array attribute of the call information by the first interceptor, determine the parameter value of the database access layer method from the second parameter, and process the parameter value by applying the method parameter name resolver mapping table in the metadata of the database access layer method to obtain the parameter array;

[0671] The sixth acquisition subunit is used to obtain the database access layer method partitioning parameter index using the partitioning information mapping table in the metadata of the database access layer method;

[0672] The seventh acquisition subunit is used to obtain the table partitioning parameters based on the table partitioning parameter index of the database access layer method and the parameter array;

[0673] The first determining subunit is used to determine the table partitioning scenario of the table partitioning parameters and obtain the table partitioning information corresponding to the table partitioning scenario. The table partitioning scenario is one of array, list, set and single object.

[0674] An execution subunit is used to execute a table partitioning process corresponding to the table partitioning scenario based on the table partitioning information, and obtain table partitioning attribute values;

[0675] The eighth acquisition subunit is used to acquire the table-specific additional information value based on the parameter array and the additional information mapping table in the metadata of the database access layer method.

[0676] In another embodiment provided by the present invention, the computing unit of the device includes:

[0677] The ninth acquisition subunit is used to acquire the table partitioning information of the database access layer method from the table partitioning information mapping table;

[0678] The tenth acquisition subunit is used to acquire the partitioning strategy from the partitioning strategy manager based on the partitioning strategy name in the partitioning information.

[0679] In another embodiment of the present invention, the reconfiguration unit of the device includes:

[0680] The second determining subunit is used to determine whether the table partitioning parameters support table partitioning based on the table partitioning information;

[0681] The splitting subunit is used to split the table splitting parameters by applying the stacking result in the table splitting index result when it is determined that the table splitting parameters support table splitting, so as to obtain each reconstructed table splitting parameter;

[0682] The third determining subunit is used to determine the table index of each of the reconstructed table parameters based on the table index information in the heap result.

[0683] This invention also provides a storage medium, which includes stored instructions, wherein the execution of the instructions controls the device where the storage medium is located to perform the above-described data processing method.

[0684] This invention also provides an electronic device, the structural schematic of which is shown below. Figure 7 As shown, it specifically includes a memory 601 and one or more instructions 602, wherein one or more instructions 602 are stored in the memory 601 and configured to be executed by one or more processors 603 to perform the above-described data processing method.

[0685] The specific implementation processes and derivative methods of the above embodiments are all within the protection scope of this invention.

[0686] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system or system embodiments, since they are basically similar to method embodiments, the description is relatively simple, and relevant parts can be referred to the descriptions in the method embodiments. The systems and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0687] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0688] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.< / string> < / string> < / string> < / string>

Claims

1. A data processing method, characterized in that, include: The currently invoked database access layer method is intercepted by a pre-defined first interceptor; The parameter annotation information of the database access layer method is parsed to obtain the metadata of the database access layer method. The metadata includes a method entity mapping table, a method parameter name parser mapping table, a table partitioning information mapping table, and an additional information mapping table. Based on the metadata of the database access layer method, obtain the table partitioning parameters, table partitioning attribute values, and table partitioning additional information values ​​from the call information of the database access layer method; The table partitioning strategy is obtained based on the table partitioning strategy name of the database access layer method. In the table partitioning strategy, the table partitioning attribute value is indexed based on the table partitioning attribute value, the table partitioning additional information value and the database access layer method information to obtain the table partitioning index result of the table partitioning attribute value. Based on the table partitioning index result, the table partitioning parameters are reconstructed to obtain each reconstructed table partitioning parameter and the table partitioning index of each reconstructed table partitioning parameter, and the table partitioning index of each reconstructed table partitioning parameter is saved to a preset table partitioning context. By using a pre-defined second interceptor based on each table index in the table partitioning context, the logical table name of the Structured Query Language (SQL) statement corresponding to each reconstructed table partitioning parameter is replaced with the actual table name, so that each reconstructed table partitioning parameter can access the database based on the actual table name of the SQL statement, and obtain the database access result of each reconstructed table partitioning parameter. The database access results of each reconstructed table parameter are aggregated to obtain the final call result of the database access layer method; The step of parsing the parameter annotation information of the database access layer method to obtain the metadata of the database access layer method includes: The first interceptor obtains the first parameter in the parameter array attribute of the call information, and obtains the underlying encapsulation object based on the first parameter; The identity attributes of the underlying encapsulated object are parsed to obtain the fully qualified class name and method name; Obtain the bytecode object corresponding to the fully qualified class name, determine the method entity in the bytecode object corresponding to the method name, and cache the determined method entity to obtain a method entity mapping table; The method parameter name resolver is obtained based on the underlying encapsulated object, and the method parameter name resolver is cached to obtain a method parameter name resolver mapping table; The table partitioning parameter annotation information of the database access layer method is obtained from the parameter annotation information. Based on the table partitioning parameter annotation information, the table partitioning parameters and the table partitioning attributes of the database access layer method are parsed to obtain the table partitioning information. The table partitioning information is cached to obtain the table partitioning information mapping table. The table partitioning additional parameter annotation information of the database access layer method is obtained from the parameter annotation information. Based on the table partitioning additional parameter annotation information, the table partitioning additional parameters of the database access layer method are parsed to obtain the table partitioning additional information. The table partitioning additional information is then cached to obtain an additional information mapping table.

2. The method according to claim 1, characterized in that, The metadata based on the database access layer method, which retrieves table partitioning parameters, table partitioning attribute values, and additional table partitioning information values ​​from the call information of the database access layer method, includes: The first interceptor obtains the second parameter from the parameter array attribute of the call information, determines the parameter value of the database access layer method from the second parameter, and processes the parameter value using the method parameter name resolver mapping table in the metadata of the database access layer method to obtain the parameter array; The database access layer method uses the table partitioning information mapping table in the metadata of the database access layer method to obtain the table partitioning parameter index of the table partitioning information; Based on the table partitioning parameter index of the database access layer method and the parameter array, the table partitioning parameters are obtained; Determine the table partitioning scenario of the table partitioning parameters, and obtain the table partitioning information corresponding to the table partitioning scenario. The table partitioning scenario is one of array, list, set and single object. Based on the table partitioning information, execute the table partitioning process corresponding to the table partitioning scenario to obtain the table partitioning attribute values; Based on the parameter array and the additional information mapping table in the metadata of the database access layer method, obtain the additional information value of the sub-table.

3. The method according to claim 1, characterized in that, The step of obtaining the table partitioning strategy based on the table partitioning strategy name of the database access layer method includes: Obtain the table partitioning information of the database access layer method from the table partitioning information mapping table; Based on the partitioning strategy name in the partitioning information, the partitioning strategy is obtained from the partitioning strategy manager.

4. The method according to claim 2, characterized in that, The step of reconstructing the table partitioning parameters based on the partitioning index result to obtain each reconstructed table partitioning parameter and the table partitioning index of each reconstructed table partitioning parameter includes: Based on the table partitioning information, determine whether the table partitioning parameters support table partitioning; When it is determined that the table partitioning parameter supports table partitioning, the table partitioning parameter is split using the stacking result in the table partitioning index result to obtain each reconstructed table partitioning parameter; Based on the table partitioning index information in the heaping results, the table partitioning index of each of the reconstructed table partitioning parameters is determined.

5. A data processing apparatus, characterized in that, include: The interception unit is used to intercept the currently invoked database access layer method through a preset first interceptor; The parsing unit is used to parse the parameter annotation information of the database access layer method and obtain the metadata of the database access layer method. The metadata includes a method entity mapping table, a method parameter name parser mapping table, a table partitioning information mapping table, and an additional information mapping table. The acquisition unit is used to acquire the table partitioning parameters, table partitioning attribute values, and table partitioning additional information values ​​from the call information of the database access layer method based on the metadata of the database access layer method. The calculation unit is used to obtain the table partitioning strategy based on the table partitioning strategy name of the database access layer method. In the table partitioning strategy, the table partitioning attribute value is indexed based on the table partitioning attribute value, the table partitioning additional information value and the database access layer method information to obtain the table partitioning index result of the table partitioning attribute value. The reconstruction unit is used to reconstruct the table partitioning parameters based on the table partitioning index result, to obtain each reconstructed table partitioning parameter and the table partitioning index of each reconstructed table partitioning parameter, and to save the table partitioning index of each reconstructed table partitioning parameter to a preset table partitioning context. The replacement unit is used to replace the logical table name of the SQL statement corresponding to each of the reconstructed table parameters with the actual table name based on each of the table indexes in the table partitioning context through a preset second interceptor, so that each of the reconstructed table parameters can access the database based on the actual table name of the SQL statement and obtain the database access result of each of the reconstructed table parameters. The aggregation unit is used to aggregate the database access results of each reconstructed table parameter to obtain the final call result of the database access layer method. The parsing unit includes: The first acquisition subunit is used by the first interceptor to acquire the first parameter in the parameter array attribute of the call information, and to acquire the underlying encapsulation object based on the first parameter; The parsing subunit is used to parse the identity attributes of the underlying encapsulated object and obtain the fully qualified class name and method name; The second acquisition subunit is used to acquire the bytecode object corresponding to the fully qualified class name, determine the method entity in the bytecode object corresponding to the method name, and cache the determined method entity to obtain a method entity mapping table. The caching subunit is used to obtain the method parameter name resolver based on the underlying encapsulated object, and cache the method parameter name resolver to obtain a method parameter name resolver mapping table; The third acquisition subunit is used to acquire the table partitioning parameter annotation information of the database access layer method from the parameter annotation information, parse the table partitioning parameters and the table partitioning attributes of the database access layer method based on the table partitioning parameter annotation information, obtain the table partitioning information, cache the table partitioning information, and obtain the table partitioning information mapping table. The fourth acquisition subunit is used to obtain the table partitioning additional parameter annotation information of the database access layer method from the parameter annotation information, parse the table partitioning additional parameters of the database access layer method based on the table partitioning additional parameter annotation information to obtain the table partitioning additional information, and cache the table partitioning additional information to obtain an additional information mapping table.

6. The apparatus according to claim 5, characterized in that, The acquisition unit includes: The fifth acquisition subunit is used to acquire the second parameter in the parameter array attribute of the call information by the first interceptor, determine the parameter value of the database access layer method from the second parameter, and process the parameter value by applying the method parameter name resolver mapping table in the metadata of the database access layer method to obtain the parameter array; The sixth acquisition subunit is used to obtain the database access layer method partitioning parameter index using the partitioning information mapping table in the metadata of the database access layer method; The seventh acquisition subunit is used to obtain the table partitioning parameters based on the table partitioning parameter index of the database access layer method and the parameter array; The first determining subunit is used to determine the table partitioning scenario of the table partitioning parameters and obtain the table partitioning information corresponding to the table partitioning scenario. The table partitioning scenario is one of array, list, set and single object. An execution subunit is used to execute a table partitioning process corresponding to the table partitioning scenario based on the table partitioning information, and obtain table partitioning attribute values; The eighth acquisition subunit is used to acquire the table-specific additional information value based on the parameter array and the additional information mapping table in the metadata of the database access layer method.

7. A storage medium, characterized in that, The storage medium includes stored instructions, wherein, when the instructions are executed, the device containing the storage medium is controlled to perform the data processing method as described in any one of claims 1-4.

8. An electronic device, characterized in that, It includes a memory, and one or more instructions, wherein one or more instructions are stored in the memory and configured to be executed by one or more processors as described in any one of claims 1-4.

Images