Method and device for function extension or modification of built-in storage engine of database

Abstract

The embodiment of the invention provides a method and device for function extension or modification of a built-in storage engine of a database, and the method comprises the steps: loading a first type of plug-in to the database when other plug-ins are not loaded and the built-in storage engine is not initialized in the initialization process of the database, the plug-in of the first type is configured to externally provide at least one callback interface associated with a built-in storage engine of the database; and registering a callback function in the at least one plug-in of the second type with a predetermined function to the at least one callback interface so as to extend or replace the function of the built-in storage engine by using the predetermined function. In this way, on the premise that source codes of the database are not modified, function extension or replacement of the built-in storage engine can be achieved.

Description

Technical Field

[0001] The exemplary embodiments disclosed herein generally relate to the field of computer technology, and more specifically, to methods and apparatus for extending or modifying the functionality of a database's built-in storage engine. Background Technology

[0002] Relational databases (such as MySQL) employ a compute-storage tiered architecture, comprising a compute layer and a storage engine layer. The various storage engines in the storage engine layer are implemented as plug-ins, adopting a flexible, pluggable architecture. Simultaneously, the storage engine layer also contains some built-in storage engines, which are embedded within the database as plug-ins and form an important component of the pluggable architecture. Summary of the Invention

[0003] In a first aspect of this disclosure, a method for extending or modifying the functionality of a database's built-in storage engine is provided. The method includes: during database initialization, and before other plugins are loaded or the built-in storage engine is initialized, loading a first-type plugin into the database, the first-type plugin being configured to provide at least one callback interface associated with the database's built-in storage engine; and registering callback functions from at least one second-type plugin having predetermined functionality to at least one callback interface to extend or replace the functionality of the built-in storage engine using predetermined functionality.

[0004] In a second aspect of this disclosure, an apparatus is provided for extending or modifying the functionality of a database's built-in storage engine. The apparatus includes: a loading module configured to load a first type of plugin into the database during database initialization, before other plugins are loaded and the built-in storage engine is initialized; the first type of plugin is configured to provide at least one callback interface associated with the database's built-in storage engine; and a registration module configured to register callback functions from at least one second type of plugin having predetermined functions to at least one callback interface, thereby extending or replacing the functionality of the built-in storage engine using predetermined functions.

[0005] In a third aspect of this disclosure, an electronic device is provided. The electronic device includes at least one processing unit; and at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions causing the electronic device to perform the method of the first aspect of this disclosure when executed by the at least one processing unit.

[0006] In a fourth aspect of this disclosure, a computer-readable storage medium is provided. This computer-readable storage medium stores a computer program that can be executed by a processor to perform the method according to a first aspect of this disclosure.

[0007] In a fifth aspect of this disclosure, a computer program product is provided. The computer program product includes computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the method according to a first aspect of this disclosure.

[0008] It should be understood that the content described in this summary section is not intended to limit the key or essential features of the embodiments of this disclosure, nor is it intended to restrict the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0009] In the following detailed description, in conjunction with the accompanying drawings, the above and other features, advantages, and aspects of the various implementations of this disclosure will become more apparent. In the accompanying drawings, the same or similar reference numerals denote the same or similar elements, wherein: Figure 1 A schematic diagram of an example environment in which embodiments of the present disclosure can be implemented is shown; Figure 2 A schematic diagram of an example architecture for the relational database MySQL is shown; Figure 3 A flowchart is shown illustrating a process for replacing the initialization callback function of the built-in storage engine according to some embodiments of the present disclosure; Figure 4 A schematic diagram illustrating an example of the operation of a predetermined callback function according to some embodiments of the present disclosure is shown; Figure 5 A schematic diagram illustrating an example of the operation of a wrapper function for creating a predetermined handle according to some embodiments of the present disclosure is shown. Figure 6 A schematic diagram illustrating an example of the operation of a packaging object according to some embodiments of the present invention is shown; Figure 7 A schematic diagram illustrating an example of parsing a specific comment information field in an SQL statement according to some embodiments of the present invention is shown; Figure 8 A flowchart is shown illustrating a process for extending or modifying the functionality of a database built-in storage engine according to some embodiments of the present disclosure; Figure 9 A block diagram of an apparatus for extending or modifying the functionality of a database built-in storage engine, according to some embodiments of the present disclosure, is shown; and Figure 10 A block diagram of an electronic device in which one or more embodiments of the present disclosure may be implemented is shown. Detailed Implementation

[0010] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0011] It should be noted that the acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0012] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The term "some embodiments" should be understood as "at least some embodiments". Other explicit and implicit definitions may also be included below.

[0013] The exemplary embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0014] Figure 1 A schematic diagram of an example environment 100 in which embodiments of the present disclosure can be implemented is shown. For example... Figure 1 As shown, example environment 100 includes client 110 and server 120. A database 130 is deployed on server 120. In some embodiments, database 130 may be a relational database, such as MySQL.

[0015] Taking the relational database MySQL as an example, MySQL includes a compute layer 140 and a storage engine layer 150. The compute layer 140 is configured to manage user connections, maintain a data dictionary, and parse, optimize, and execute Structured Query Language (SQL) statements. Furthermore, the compute layer 140 can utilize a built-in plugin submodule 142 to achieve unified management of various plugins. For example, a plugin can complete its registration process with the compute layer 140 through a context object of a fixed format (e.g., a data structure of type `st_mysql_plugin`).

[0016] The storage engine layer 150 may include, for example, the native in-memory table storage engine 152 (Heap) and the native transaction table storage engine (InnoDB) 154. The context object of the native in-memory table storage engine 152 is named "heap", and the context object of the native transaction table storage engine 154 is named "innobase".

[0017] The context object can contain a "name" field and an "init" field. The "name" field stores the plugin name, and the "init" field points to the plugin's initialization callback function. When loading a plugin, the corresponding context object needs to be registered with the computation layer 140, and the "init()" callback function in the corresponding context object also needs to be called to complete the plugin initialization.

[0018] For embedded plugins, the plugin submodule 142 maintains a pointer array (mysql_mandatory_plugins) 144. Each item in the pointer array 144 points to a context object corresponding to an embedded plugin. During the MySQL startup phase, the pointer array 144 can be traversed, and the initialization work of all embedded plugins can be completed in sequence.

[0019] For plugins based on storage engine type, MySQL additionally defines two context interfaces: the global metadata interface handlerton (e.g., heap_hton 146 and innodb_hton 148) and the single table operation interface handler (e.g., ha_innobase 156 and ha_innopart 158).

[0020] The global metadata interface `handlerton` is a singleton structure in MySQL used to define the global functionality of a storage engine. As the core link between the compute layer 140 and the storage engine layer 150, it encapsulates a set of pointers to a series of global functional interfaces, including transaction management, tablespace operations, and connection control. During the initialization phase, each storage engine populates a `handlerton` instance and registers its own global behaviors through this structure, including interfaces such as `commit`, `rollback`, and `create`.

[0021] As an example, a partial implementation of the innodb_init() function is as follows:

[0022] Referring to the example above, when a query needs to open an InnoDB table, the callback function innodb_hton->create() needs to be called to create the corresponding handler object and associate it with the MySQL TABLE object (i.e., assign table->file = handler).

[0023] The single-table operation interface handler is a dedicated working object instantiated by the storage engine for each table. It is responsible for handling various local operations on that table, such as data scanning, index lookup, data insertion, and updates. The handler operates through... Method families (e.g., ha_open, ha_index_read, etc.) implement specific functionalities, while also providing built-in table structure pointers. And storage engine-specific context information.

[0024] The scope of the single-table operation interface `handler` is limited to table-level operations, while the global metadata interface `handlerton` is responsible for managing the global state of the storage engine. Taking the native transactional table storage engine 154 as an example, it implements two handler types: one is `ha_innobase` 156, used for operating on ordinary tables; the other is `ha_innopart` 158, specifically used for operating on partitioned tables. The partitioned tables of the native transactional table storage engine 154 are essentially encapsulations of ordinary data tables, combining multiple ordinary data tables to simulate a complete logical table.

[0025] In environment 100, client 110 can send instructions related to database 130 to server 110, and server 120 can instruct database 130 to perform operations related to the received instructions. In some embodiments, client 110 and server 120 can be deployed in different electronic devices. It should be understood that the electronic device can be a single device or a cluster of multiple independent devices that are communicatively connected.

[0026] In environment 100, electronic devices can be any type of computing-capable device, including terminal devices or server devices. Terminal devices can be any type of mobile terminal, fixed terminal, or portable terminal, including mobile phones, desktop computers, laptop computers, notebook computers, netbook computers, tablet computers, media computers, multimedia tablets, personal communication system (PCS) devices, personal navigation devices, personal digital assistants (PDAs), audio / video players, digital cameras / camcorders, positioning devices, television receivers, radio receivers, e-book devices, gaming devices, or any combination of the foregoing, including accessories and peripherals of these devices or any combination thereof. Server devices can include, for example, computing systems / servers, such as mainframes, edge computing nodes, computing devices in cloud environments, and so on.

[0027] It should be understood that the structure and function of environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of this disclosure.

[0028] As briefly mentioned above, the various storage engines in the storage engine layer of relational databases (such as MySQL) are implemented as plug-ins, adopting a flexible, pluggable architecture. At the same time, there are also some built-in storage engines in the storage engine layer. These storage engines are embedded in the database as plug-ins and are an important part of the pluggable architecture.

[0029] For pluggable storage engines, hot upgrades can be performed by uninstalling and reinstalling. For example, the storage engine code can be modified to add new features and released as a plugin. However, the database's built-in storage engine is loaded in an embedded mode and cannot be hot-swapped. Adding features to the native engine requires modifying the database's kernel code and recompiling. Updating the built-in storage engine's functionality requires replacing the database program code and then restarting the database for the changes to take effect. Furthermore, the ability to monitor the native engine is limited by the database's built-in mechanisms, making it impossible to add audit items online.

[0030] To at least partially address the aforementioned problems and other potential issues in conventional solutions, this disclosure provides a solution for database management. According to various embodiments of this disclosure, during database initialization, before other plugins are loaded or the built-in storage engine is initialized, a first type of plugin is loaded into the database. This first type of plugin is configured to provide at least one callback interface associated with the database's built-in storage engine. Callback functions from at least one second type of plugin with predetermined functionality are registered to at least one callback interface to extend or replace the functionality of the built-in storage engine using predetermined functions. In this way, the functionality of the built-in storage engine can be extended or replaced without modifying the database source code.

[0031] The exemplary embodiments of this disclosure will now be described in detail with reference to the accompanying drawings. Figure 1 The database 130 in this example is MySQL, which is used to describe an exemplary embodiment of this disclosure in detail. It should be understood that database 130 can also be other relational databases, and this disclosure does not limit it. Figure 2 It shows Figure 1 Example architecture 200 of the computation layer 140 of the database 130. Next, we will combine... Figure 1 This disclosure provides a detailed description of the database management solution.

[0032] like Figure 2As shown, the plugins loaded into the computing layer 140 can be divided into three types according to the timing of their loading: early-loaded plugins, mandatory plugins, and optional plugins. Early-loaded plugins are loaded during the initialization of the database 130, before other plugins and the built-in storage engine are initialized. Mandatory plugins are loaded subsequently, and finally, optional plugins specified in the startup parameters and configuration file are loaded.

[0033] Using the above mechanism, server 120 can load an early-loading plugin, namely storage engine wrapper plugin 210, when database 130 starts. This allows storage engine wrapper plugin 210 to hijack the built-in storage engine of database 130 and provide at least one callback interface associated with that built-in storage engine. Next, server 120 loads an optional plugin with predetermined functions, namely storage engine extension plugin 220, registering the callback functions in storage engine extension plugin 220 with at least one callback interface provided by storage engine wrapper plugin 210. This allows server 120 to extend or replace the functionality of the built-in storage engine of database 130 using the predetermined functions of storage engine extension plugin 220. In this document, storage engine wrapper plugin 210 is sometimes referred to as a "first-type plugin," and storage engine extension plugin 220 is sometimes referred to as a "second-type plugin."

[0034] The following example illustrates the functional extension of the native transactional table storage engine (InnoDB) 154. It should be understood that this functional extension of the native transactional table storage engine is merely illustrative and not intended to impose any limitations.

[0035] During the startup phase of storage engine wrapper plugin 210 (i.e., when database 130 loads storage engine wrapper plugin 210), server 120 first searches the context pointer array `mysql_mandatory_plugins` associated with database 130 using storage engine wrapper plugin 210 for the context object associated with native transaction table storage engine 154. For example, storage engine wrapper plugin 210 can traverse the context pointer array associated with database 130 based on the identifier (name) of native transaction table storage engine 154 to determine the context object associated with native transaction table storage engine 154. Subsequently, server 120 replaces the initialization callback function pointer (“init” pointer) in the determined context object with the function address of the predetermined callback function (wrapper_engine_init) using storage engine wrapper plugin 210.

[0036] Figure 3A process 300 for replacing the initialization callback function of the built-in storage engine according to some embodiments of the present disclosure is illustrated. For example, process 300 may be implemented in Figure 1 In server 120.

[0037] like Figure 3 As shown, during the startup phase of storage engine wrapper plugin 210 (i.e., when database 130 loads the early loading plugin), in box 310, server 120, through storage engine wrapper plugin 210, uses the identifier (name) of native transaction table storage engine 154 to traverse the array of context pointers associated with database 130, thereby determining the context object associated with native transaction table storage engine 154 from the context pointer array. In box 320, server 120 uses storage engine wrapper plugin 210 to cache innobase->init (i.e., the address of the innobase_init function) in the context object. In box 330, server 120, through storage engine wrapper plugin 210, replaces the initialization callback function pointer (“init” pointer) in the determined context object with the function address of the predetermined callback function (wrapper_engine_init).

[0038] When database 130 loads native transactional table storage engine 154, it needs to call the init callback in the context object of native transactional table storage engine 154, namely innobase->init(), so as to execute the predefined callback function wrapper_engine_init.

[0039] Figure 4 Example 400 illustrates the operation of a predetermined callback function according to some embodiments of this disclosure. For example, process 400 may be implemented in... Figure 1 In server 120.

[0040] like Figure 4As shown, when database 130 loads the native transactional table storage engine 154, in box 410, server 120 executes the `innobase_init` function through storage engine wrapper plugin 210 to populate `innodb_hton`. That is, it calls the `init` callback in the context object of the native transactional table storage engine 154, i.e., `innobase->init()`, to initialize the native transactional table engine 154 by populating `innodb_hton` 148 to update the attribute information of the context object associated with the native transactional table storage engine 154. In box 420, server 120 caches the native handle creation function (`innobase_create_handler`) pointed to by the handle creation function pointer (`innodb_hton->create`) in the updated context object through storage engine wrapper plugin 210. In box 430, server 120 replaces the address of the native handle creation function pointed to in the handle creation function pointer with the address of the predetermined handle creation wrapper function (`wrapper_handler_creator()`). In box 440, server 120 uses storage engine wrapper plugin 210 to create a wrapper object for a data table handle instance of the built-in storage engine using a predefined handle creation wrapper function.

[0041] As an example, the predefined callback function (wrapper_engine_init) can be implemented as follows:

[0042] The above example demonstrates how to initialize the native transactional table storage engine 154 and hijack the global metadata interface handlerton. Subsequently, when opening an InnoDB table and attempting to instantiate an InnoDB single-table operation interface handler object, the hijacking will occur via the pre-defined callback function (wrapper_engine_init). This pre-defined callback function can instantiate a wrapper object (handler_wrapper) for the single-table operation interface handler.

[0043] Figure 5 Example 500 illustrates the working process of a predefined handle creation wrapper function according to some embodiments of the present disclosure. For example, process 500 can be implemented in... Figure 1 In server 120.

[0044] like Figure 5As shown in box 510, server 120 instantiates a wrapper object through storage engine wrapper plugin 210. In box 520, server 120 executes the `innobase_create_handler` function through storage engine wrapper plugin 210, instantiating a single-table operation interface handler object of the native transactional table storage engine 154. In box 530, server 120 sets `Handler_wrapper::m_file` to a pointer to the newly created single-table operation interface handler object through storage engine wrapper plugin 210. In box 540, server 120 returns a pointer to the wrapper object (`handler_wrapper`) through storage engine wrapper plugin 210.

[0045] As an example, the predefined handle creation wrapper function (wrapper_handler_creator) can be implemented as follows:

[0046] In the example above, the `Handler_wrapper` class inherits from the MySQL `handler` class and is a wrapper around the native transactional table storage engine 154. Its purpose is to inject extended callbacks when calling the single-table operation interface `handler`. The declaration of the wrapper object (`handler_wrapper`) is as follows:

[0047] The example above illustrates how the wrapper function for the single-table operation interface handler is implemented. For easier understanding, the following section will combine... Figure 6 Let me explain further. Figure 6 Example 600 illustrates the working process of a packaged object according to some embodiments of the present invention. For example, process 600 can be implemented in... Figure 1 In server 120.

[0048] like Figure 6As shown, in box 610, server 120 obtains the MySQL thread context (current_thd). In box 620, server 120 determines, based on the thread context, whether storage engine extension plugin 220 is registered to the pre-callback interface in the callback interface. If storage engine extension plugin 220 is not registered to the pre-callback interface, in box 630, the server calls the interface with the same name as the native handle creation function of the native transaction table storage engine 154, i.e., m_file->xxx(xxx_arguments). In box 640, server 120 determines, based on the thread context, whether storage engine extension plugin 220 is registered to the post-callback interface in the callback interface. If storage engine extension plugin 220 is registered to the post-callback interface, in box 650, the post-callback of the current interface is called, i.e., xxx_after(current_thd,m_file,result_val,xxx_arguments). In box 660, server 120 determines whether the post-callback has failed. If it is determined that the post-callback has not failed, the return value of the post-callback is returned. When it is determined that the callback has failed, return the return value of the native function.

[0049] When storage engine extension plugin 220 is registered to the before callback interface, in box 670, server 120 calls the before callback associated with the before callback interface, i.e., xxx_before(current_thd, m_file, xxx_arguments). In box 680, server 120 determines whether the before callback is invalid. If the before callback is invalid, the return value of the before callback is returned. If the before callback is not invalid, box 630 is executed. If storage engine extension plugin 220 is not registered to the after callback interface, the return value of the native function is returned.

[0050] In some embodiments, the storage engine extension plugin 220 supports hot upgrades. During an upgrade, the currently registered interfaces of the storage engine extension plugin 220 can be unregistered first, and then the storage engine extension plugin 220 can be uninstalled. Subsequently, the new version of the storage engine extension plugin 220 can be installed, thereby updating the extended functionality of the native transaction table storage engine 154 while the database is running normally.

[0051] In some embodiments, when the storage engine extension plugin 220 is removed (e.g., uninstalled), the corresponding functionality of the native transaction table storage engine 154 is also removed.

[0052] In some embodiments, server 120 may also utilize storage engine extension plugin 220 to parse specific comment information fields (e.g., HINTs) in the SQL statement sent via client 110 to obtain instructions and / or parameters associated with predetermined functions of storage engine extension plugin 220, and use these instructions and / or parameters to update the predetermined functions of storage engine extension plugin 220. Since the HINT injection occurs after the first keyword of the SQL statement and its format is fixed, parsing HINTs does not impact database performance. Furthermore, for a single SQL statement, HINTs can be parsed only once and cached, thereby avoiding multiple parsings of the same HINT, further reducing the impact on database performance.

[0053] Figure 7 Example 700 of parsing a specific comment information field in an SQL statement according to some embodiments of the present invention is shown. Figure 7 As shown, database 130 can maintain a thread context (current_thd) for the connection to client 110. This thread context stores the currently executing SQL statement in the corresponding field, i.e., current_thd->m_query_string. Storage engine extension plugin 220 can access this SQL statement. Specific annotation information fields in This performs parsing to update the functionality of the storage engine extension plugin 220.

[0054] It should be understood that a HINT is a special instruction that can be embedded in SQL statements to provide execution suggestions to the database optimizer. It is not a mandatory command, but rather a "hint" to the database, helping it choose a more efficient execution plan. For example, in complex queries, HINTs can be used to specify which index to use, which join method to employ, or to control the parallelism of the query. Different database systems (e.g., MySQL, Oracle, SQL Server, etc.) have slightly different support and syntax for HINTs.

[0055] In summary, according to the embodiments of this disclosure, by providing a callback interface through a storage engine wrapper plugin and registering the callback functions of the storage engine extension plugin with predetermined functions to the callback interface, the functionality of the built-in storage engine can be extended or replaced without modifying the database source code. Simultaneously, when updating the extended functionality of the built-in storage engine, instructions or parameters can be passed via HINTs without adding new parameters or interfaces.

[0056] Figure 8A flowchart of process 800 for extending or modifying the functionality of a database's built-in storage engine, according to some embodiments of this disclosure, is shown. Process 800 may be implemented in server 120.

[0057] In box 810, during the database initialization process, and before other plugins are loaded or the built-in storage engine is initialized, server 120 loads a first type of plugin into the database. The first type of plugin is configured to provide at least one callback interface associated with the database's built-in storage engine.

[0058] In box 820, server 120 registers callback functions from at least one second-type plugin with predetermined functions to at least one callback interface to extend or replace the functionality of the built-in storage engine using the predetermined functions.

[0059] In some embodiments, at least one callback interface is determined by: replacing the initialization callback function of the built-in storage engine with a predetermined callback function; and using the predetermined callback function, creating a wrapper object for a data table handle instance of the built-in storage engine, the wrapper object being configured to encapsulate at least one function interface in the data table handle instance of the built-in storage engine and providing external access for extending or replacing at least one callback interface.

[0060] In some embodiments, the callback interface in at least one callback interface includes a pre-callback interface and a post-callback interface, and the wrapper object is further configured to: for a target plugin in at least one second-type plugin, in response to the callback function in the target plugin being registered to the pre-callback interface, invoke the pre-callback associated with the pre-callback interface when at least one callback interface is triggered; in response to the normal execution of the pre-callback, invoke the function interface corresponding to the data table handle instance of the built-in storage engine, or in response to the return value of the pre-callback indicating the end of this call, not invoke the function interface corresponding to the data table handle instance of the built-in storage engine; and in response to the completion of the function interface corresponding to the data table handle instance of the native handle creation function being called and the target plugin being registered to the post-callback interface, trigger the post-callback associated with the post-callback interface.

[0061] In some embodiments, replacing the initialization callback function with a predetermined callback function includes: determining a context object associated with the built-in storage engine based on the identifier of the built-in storage engine and an array of context pointers associated with the database; and updating the initialization callback function pointer in the context object with the function address of the predetermined callback function.

[0062] In some embodiments, the wrapper object is created by: calling an initialization callback function to perform initialization operations on the built-in storage engine to update the attribute information of the context object associated with the built-in storage engine; caching the native handle creation function pointer pointed to by the handle creation function pointer in the updated context object; updating the address of the native handle creation function pointed to by the handle creation function pointer to the address of the predetermined handle creation wrapper function; and using the predetermined handle creation wrapper function to create a wrapper object for the data table handle instance of the built-in storage engine.

[0063] In some embodiments, at least one second-type plugin is configured to: parse specific annotation information fields in the structured query language (SQL) received from the database to obtain instructions and / or parameters associated with a predetermined function; and update the predetermined function using the instructions and / or parameters.

[0064] In some embodiments, process 800 includes updating a second type of plugin registered to the callback interface.

[0065] In some embodiments, process 800 further includes: in response to the removal of at least one second-type plugin, removing functionality corresponding to the removed second-type plugin from the functionality of the extended built-in storage engine.

[0066] Figure 9 A block diagram of an apparatus 900 for extending or modifying the functionality of a database built-in storage engine, according to some embodiments of the present disclosure, is shown. The apparatus 900 may be implemented in a server 120. Various modules / components in the apparatus 900 may be implemented by hardware, software, firmware, or any combination thereof.

[0067] The apparatus 900 includes a loading module 910 configured to load a first type of plugin into the database during database initialization, before other plugins are loaded or the built-in storage engine is initialized. The first type of plugin is configured to provide at least one callback interface associated with the database's built-in storage engine. The apparatus 900 also includes a registration module 920 configured to register callback functions from at least one second type of plugin with predetermined functionality to at least one callback interface, thereby extending or replacing the functionality of the built-in storage engine using predetermined functions.

[0068] In some embodiments, at least one callback interface is determined by: replacing the initialization callback function of the built-in storage engine with a predetermined callback function; and using the predetermined callback function, creating a wrapper object for a data table handle instance of the built-in storage engine, the wrapper object being configured to encapsulate at least one function interface in the data table handle instance of the built-in storage engine and providing a callback interface for at least one function interface to the outside world.

[0069] In some embodiments, the callback interface in at least one callback interface includes a pre-callback interface and a post-callback interface, and the wrapper object is further configured to: for a target plugin in at least one second-type plugin, in response to the callback function in the target plugin being registered to the pre-callback interface, invoke the pre-callback associated with the pre-callback interface when at least one callback interface is triggered; in response to the normal execution of the pre-callback, invoke the function interface corresponding to the data table handle instance of the built-in storage engine, or in response to the return value of the pre-callback indicating the end of this call, not invoke the function interface corresponding to the data table handle instance of the built-in storage engine; and in response to the completion of the function interface corresponding to the data table handle instance of the native handle creation function being called and the target plugin being registered to the post-callback interface, trigger the post-callback associated with the post-callback interface.

[0070] In some embodiments, replacing the initialization callback function with a predetermined callback function includes: determining a context object associated with the built-in storage engine based on the identifier of the built-in storage engine and an array of context pointers associated with the database; and updating the initialization callback function pointer in the context object with the function address of the predetermined callback function.

[0071] In some embodiments, the wrapper object is created by: calling an initialization callback function to perform initialization operations on the built-in storage engine to update the attribute information of the context object associated with the built-in storage engine; caching the native handle creation function pointer pointed to by the handle creation function pointer in the updated context object; updating the address of the native handle creation function pointed to by the handle creation function pointer to the address of the predetermined handle creation wrapper function; and using the predetermined handle creation wrapper function to create a wrapper object for the data table handle instance of the built-in storage engine.

[0072] In some embodiments, at least one second-type plugin is configured to: parse specific annotation information fields in the structured query language (SQL) received from the database to obtain instructions and / or parameters associated with a predetermined function; and update the predetermined function using the instructions and / or parameters.

[0073] In some embodiments, the device 900 further includes an update module configured to update a second type of plugin registered to the callback interface.

[0074] In some embodiments, the apparatus 900 further includes a removal module configured to remove functionality corresponding to the removed second-type plugin from the functionality of the extended built-in storage engine in response to the removal of at least one second-type plugin.

[0075] The units included in device 900 can be implemented in various ways, including software, hardware, firmware, or any combination thereof. In some embodiments, one or more units may be implemented using software and / or firmware, such as machine-executable instructions stored on a storage medium. In addition to or as an alternative to machine-executable instructions, some or all of the units in device 900 may be implemented at least partially by one or more hardware logic components. By way of example, and not limitation, exemplary types of hardware logic components that may be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-chips (SoCs), complex programmable logic devices (CPLDs), and so on.

[0076] Figure 10 A block diagram of an electronic device 1000 in which one or more embodiments of the present disclosure may be implemented is shown. It should be understood that... Figure 10 The electronic device 1000 shown is merely exemplary and should not be construed as limiting the functionality and scope of the embodiments described herein. Figure 10 The electronic device 1000 shown can be used to achieve Figure 1 Server 120.

[0077] like Figure 10 As shown, electronic device 1000 is in the form of a general-purpose electronic device. Components of electronic device 1000 may include, but are not limited to, one or more processors or processing units 1010, memory 1020, storage device 1030, one or more communication units 1040, one or more input devices 1050, and one or more output devices 1060. Processing unit 1010 may be a physical or virtual processor and is capable of performing various processes according to programs stored in memory 1020. In a multiprocessor system, multiple processing units execute computer-executable instructions in parallel to improve the parallel processing capability of electronic device 1000.

[0078] Electronic device 1000 typically includes multiple computer storage media. Such media can be any available media accessible to electronic device 1000, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 1020 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. Storage device 1030 can be a removable or non-removable medium and can include machine-readable media, such as flash drives, disks, or any other media that can be used to store information and / or data (e.g., training data for training) and can be accessed within electronic device 1000.

[0079] Electronic device 1000 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not explicitly stated... Figure 10 As shown, disk drives for reading from or writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks can be provided. In these cases, each drive can be connected to a bus (not shown) via one or more data media interfaces. Memory 1020 may include computer program product 1025 having one or more program modules configured to perform various methods or actions of various embodiments of this disclosure.

[0080] The communication unit 1040 enables communication with other electronic devices via a communication medium. Additionally, the functionality of the components of the electronic device 1000 can be implemented using a single computing cluster or multiple computing machines capable of communicating via communication connections. Therefore, the electronic device 1000 can operate in a networked environment using logical connections to one or more other servers, network personal computers (PCs), or another network node.

[0081] Input device 1050 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 1060 can be one or more output devices, such as a monitor, speaker, printer, etc. Electronic device 1000 can also communicate with one or more external devices (not shown) via communication unit 1040 as needed. These external devices include storage devices, display devices, etc., and can communicate with one or more devices that enable user interaction with electronic device 1000, or with any device that enables electronic device 1000 to communicate with one or more other electronic devices (e.g., network card, modem, etc.). Such communication can be performed via input / output (I / O) interface (not shown).

[0082] According to an exemplary implementation of this disclosure, a computer-readable storage medium is provided that stores one or more computer instructions, wherein the one or more computer instructions are executed by a processor to implement the methods described above. According to an exemplary implementation of this disclosure, a computer program product is also provided, which is tangibly stored on a non-transient computer-readable medium and includes computer-executable instructions that are executed by a processor to implement the methods described above.

[0083] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products implemented according to this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0084] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processing unit of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0085] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0086] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0087] Various implementations of this disclosure have been described above. The foregoing description is exemplary and not exhaustive, nor is it limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the implementations disclosed herein.

Claims

1. A method for extending or modifying the functionality of a database's built-in storage engine, comprising: During database initialization, and before other plugins or the built-in storage engine are loaded, a first type of plugin is loaded into the database. The first type of plugin is configured to provide at least one callback interface associated with the built-in storage engine of the database. as well as Register callback functions from at least one second-type plugin with predetermined functions to the at least one callback interface to extend or replace the functionality of the built-in storage engine using the predetermined functions.

2. The method according to claim 1, wherein the at least one callback interface is determined in the following manner: Replace the initialization callback function of the built-in storage engine with a predetermined callback function; and Using the predetermined callback function, a wrapper object is created for the data table handle instance of the built-in storage engine. The wrapper object is configured to encapsulate at least one function interface in the data table handle instance of the built-in storage engine and provide a callback interface for extending or replacing the at least one function interface.

3. The method according to claim 2, wherein the callback interface in the at least one callback interface includes a pre-callback interface and a post-callback interface, and wherein the wrapper object is further configured to: For the target plugin in at least one of the second type of plugins, In response to the callback function in the target plugin being registered to the pre-callback interface, when the at least one callback interface is triggered, the pre-callback associated with the pre-callback interface is invoked. In response to the normal execution of the preceding callback, the function interface corresponding to the data table handle instance of the built-in storage engine is called; or in response to the return value of the preceding callback indicating the end of this call, the function interface corresponding to the data table handle instance of the built-in storage engine is not called. as well as In response to the completion of the function interface corresponding to the data table handle instance of the native handle creation function being called, and the target plugin being registered to the post-callback interface, the post-callback associated with the post-callback interface is triggered.

4. The method of claim 2, wherein replacing the initialization callback function with the predetermined callback function comprises: Based on the identifier of the built-in storage engine and the array of context pointers associated with the database, determine the context object associated with the built-in storage engine; as well as Update the initialization callback function pointer in the context object to the function address of the predetermined callback function.

5. The method of claim 2, wherein the packaging object is created in the following manner: The initialization callback function is invoked to perform an initialization operation on the built-in storage engine, thereby updating the attribute information of the context object associated with the built-in storage engine; The cached native handle creation function is pointed to by the handle creation function pointer in the updated context object; Update the address of the native handle creation function pointed to in the handle creation function pointer to the address of the predetermined handle creation wrapper function; as well as Using the predetermined handle creation wrapper function, a wrapper object is created for the data table handle instance of the built-in storage engine.

6. The method of claim 1, wherein the at least one second-type plugin is configured to: Parse specific comment information fields in the Structured Query Language (SQL) received from the database to obtain instructions and / or parameters associated with the predetermined function; and Update the predetermined function using the instructions and / or parameters.

7. The method according to claim 1, further comprising: Update the second type of plugin registered to the callback interface.

8. The method according to claim 1, further comprising: In response to the removal of at least one second-type plugin, the functionality corresponding to the removed second-type plugin is removed from the extended functionality of the built-in storage engine.

9. An apparatus for extending or modifying the functionality of a database's built-in storage engine, comprising: The loading module is configured to load a first type of plugin into the database during the database initialization process, before other plugins are loaded and the built-in storage engine is initialized. The first type of plugin is configured to provide at least one callback interface associated with the built-in storage engine of the database. as well as The registration module is configured to register callback functions from at least one second-type plugin with predetermined functions to the at least one callback interface in order to extend or replace the functionality of the built-in storage engine using the predetermined functions.

10. An electronic device, comprising: At least one processing unit; as well as At least one memory, coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, which, when executed by the at least one processing unit, cause the electronic device to perform the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program stored thereon, the computer program being executable by a processor to implement the method according to any one of claims 1 to 8.

12. A computer program product comprising computer-executable instructions, wherein the computer-executable instructions, when executed by a processor, implement the method according to any one of claims 1 to 8.

Images