An XML-based database operation method and system

Abstract

The application discloses an XML-based database operation method and system, and relates to the technical field of computers.The method comprises the following steps: loading and analyzing a first XML configuration file without a third-party plug-in to create a first database subsystem; loading and analyzing an XML operation message to extract operation analysis data; performing feature matching analysis on the analysis data; if there is no matching result, generating an SQL statement, executing the operation through an API of the first database subsystem, and returning an execution result.The technical problem of low development efficiency caused by the complexity and strong dependency of the XML data and database interaction process in the prior art is solved, the XML data analysis and database operation are encapsulated into a general interface, and the technical effects of simplifying the XML data and database interaction process, reducing development dependency, and improving development efficiency are achieved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a database operation method and system based on XML. BACKGROUND

[0002] With XML becoming the mainstream format of data transmission between client and server, its application in database interaction is increasingly widespread. However, the processing process of XML data and database interaction in the prior art is complex, and usually requires converting XML format data into binary structure in advance, and writing specific operation code for different databases, which puts forward higher requirements for developers. In addition, when the system adapts to different databases or processes new XML message formats, the underlying code often needs to be modified, increasing the development and maintenance cost, and it is difficult to meet the dynamic changing business requirements. In view of the above problems, the industry urgently needs a technical solution that can simplify the XML data processing process and effectively reduce the system complexity.

[0003] At present, in the related art, there is a technical problem that the XML data and database interaction process is complex and dependent, resulting in low development efficiency. SUMMARY

[0004] The present application provides a database operation method and system based on XML, which solves the technical problem that the XML data and database interaction process is complex and dependent in the prior art, resulting in low development efficiency.

[0005] The present application provides a database operation method based on XML, comprising:

[0006] loading a first XML configuration file, parsing the first XML configuration file to create a first database subsystem, wherein the first XML configuration file is an XML configuration file that does not need to be processed by a third-party plug-in; loading an XML operation message, performing operation analysis on the XML operation message to obtain operation analysis data; performing feature item matching analysis on the operation analysis data, and if the matching analysis result returns empty, generating a SQL operation statement according to the operation analysis data, calling the API of the first database subsystem to execute the SQL operation statement, and returning the execution result of the XML operation message.

[0007] The present application provides a database operation system based on XML, comprising:

[0008] The first XML configuration file loading module is used for loading a first XML configuration file, parsing the first XML configuration file to create a first database subsystem, wherein the first XML configuration file is an XML configuration file which does not need to be processed by a third-party plug-in; the operation message loading module is used for loading an XML operation message, performing operation analysis on the XML operation message to obtain operation analysis data; the operation statement generation module is used for performing feature item matching analysis on the operation analysis data, generating an SQL operation statement according to the operation analysis data if the matching analysis result is returned as empty, calling an API of the first database subsystem to execute the SQL operation statement, and returning an execution result of the XML operation message.

[0009] The XML-based database operation method and system provided in the application first load and parse a first XML configuration file which does not need a third-party plug-in to create a first database subsystem, load and parse an XML operation message to extract operation analysis data, perform feature matching analysis on the analysis data, generate an SQL statement if there is no matching result, execute the operation through an API of the first database subsystem, and return an execution result, so that XML data analysis and database operation are encapsulated as a general interface, the XML data and database interaction process is simplified, development dependence is reduced, and development efficiency is improved. BRIEF DESCRIPTION OF DRAWINGS

[0010] Figure 1 A flowchart of an XML-based database operation method provided in an embodiment of the application is shown in the figure.

[0011] Figure 2 A structure diagram of an XML-based database operation system provided in an embodiment of the application is shown in the figure.

[0012] Figure 3 A flowchart of a first database subsystem creation process of an XML-based database operation method provided in an embodiment of the application is shown in the figure.

[0013] Figure 4 A first database subsystem operation flowchart of an XML-based database operation method provided in an embodiment of the application is shown in the figure.

[0014] Figure 5 A second database subsystem data processing flowchart of an XML-based database operation method provided in an embodiment of the application is shown in the figure.

[0015] The reference signs are explained as follows: a first XML configuration file loading module 10, an operation message loading module 20, and an operation statement generation module 30. DETAILED DESCRIPTION

[0016] The above description is only a summary of the technical solutions of the present application. In order to make the technical means of the present application more clearly understood, and to be implemented according to the content of the description, and in order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the following specific embodiments of the present application are described.

[0017] In order to make the purposes, technical solutions and advantages of the present application more clear, the following will further describe the present application with reference to the accompanying drawings, and the described embodiments should not be regarded as limiting the present application. All other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0018] In the following description, "some embodiments" are related to a subset of all possible embodiments, but it can be understood that "some embodiments" can be the same subset or different subset of all possible embodiments, and can be combined with each other without conflict, and the term "first\second" involved only distinguishes similar objects, and does not represent the specific order of the objects. The terms "include" and "have" and any variations, are intended to cover non-exclusive inclusion, for example, a process, method, system, product or server including a series of steps or units does not have to be limited to those steps or units clearly listed, but can include other steps or modules that are not clearly listed or inherent to these processes, methods, products or devices. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as understood by those skilled in the art to which the present application belongs. The terms used herein are only for the purpose of describing the embodiments of the present application.

[0019] The embodiments of the present application provide an XML-based database operation method, as shown in Figure 1 The method comprises the following steps:

[0020] In step S100, a first XML configuration file is loaded, and the first XML configuration file is parsed to create a first database subsystem, wherein the first XML configuration file is an XML configuration file that does not need to be processed by a third-party plug-in. As shown in Figure 3As shown, specifically, the system loads the first XML configuration file, which contains the basic configuration information of the database system, such as database connection parameters, table structure, field definition, etc. After loading the file, the system parses the XML file through the built-in parser, and the parsing process does not depend on any third-party plug-in, reducing external dependencies and making the system more efficient and easy to maintain. During the parsing process, the system will read the XML file item by item, extract key information such as the location of the database file, the name of the table, the type and constraint condition of the field, etc., to ensure that the configuration can be correctly identified. Then, based on the parsed data, the system automatically builds the first database subsystem, including generating the database file, establishing the data table, and configuring the table structure according to the field definition and constraint condition. The entire process is based entirely on the XML configuration file and is implemented without using any additional plug-ins, thereby reducing the complexity of the system, improving the execution efficiency and flexibility. The system can complete the automatic creation and configuration of the database without relying on external tools, adapting to different business needs.

[0021] In a possible implementation, as Figure 3As shown, a first XML configuration file is loaded and parsed to create a first database subsystem, wherein the first XML configuration file is an XML configuration file that does not require third-party plugins for processing, and step S100 further includes step S110 of parsing the first XML configuration file to obtain a database file node, a database table node, and a data table default value node. Specifically, the first XML configuration file is first loaded and parsed to extract the database file node, the database table node, and the data table default value node, so as to create the database subsystem. Specifically, by parsing the database file node, the system can obtain the path and storage location of the database file and other information, and then determine whether a new database file needs to be created. If the file does not exist, the system will automatically create the file according to the configuration, ensuring that the database file is correctly initialized and located at the specified location. Next, the system parses the database table node to extract table structure information in the database, including the name, fields, and field types of each table. For example, it may contain a table named "user" with fields "user ID", "username", "registration date", etc., and each field may correspond to different data types such as integer, string, or date type. By obtaining the information, the system can create the corresponding structure for each table according to the requirements of the configuration file, ensuring that the design of the database meets the expectations. Finally, the system also parses the data table default value node to extract the default value information of each field. These default values are crucial for the initialization of fields in the database, especially when inserting data, some fields may not have explicit values, at this time the system will use the default values defined in the configuration file to fill in the fields, ensuring data consistency and integrity. For example, for the "registration date" field, the system may use the current date as the default value to automatically fill in the field value. These steps ensure that the creation and initialization of the database subsystem not only meet the design requirements, but also handle various data missing situations.

[0022] Step S120, according to the database file node, database table node and data table default value node, create the first database subsystem. Specifically, the process of creating the first database subsystem first needs to obtain the database file node, database table node and data table default value node by parsing the first XML configuration file. The database file node specifies the path and name of the database file, and if there is no corresponding database file under the path, the system will automatically create a new file. Then, the system parses the database table node, which defines each data table to be created and its field information, including field name, type, etc. For example, if the node defines the "user" table and its fields "user ID" (int type), "username" (varchar type), "registration date" (date type), the system will create the table structure according to the information. Then, the system parses the data table default value node to set the default value of the field, for example, if the "registration date" field does not provide a value, the system will automatically fill in the current date to ensure the integrity and consistency of the data. Through the above steps, the system successfully creates the database file and table structure, and specifies appropriate default values for the fields, ensuring that the database subsystem functions normally and the data is complete.

[0023] In one possible implementation, as shown in Figure 3 Step S120, according to the database file node, database table node and data table default value node, create the first database subsystem. Specifically, the process of creating the first database subsystem first needs to obtain the database file node, database table node and data table default value node by parsing the first XML configuration file. The database file node specifies the path and name of the database file, and if there is no corresponding database file under the path, the system will automatically create a new file. Then, the system parses the database table node, which defines each data table to be created and its field information, including field name, type, etc. For example, if the node defines the "user" table and its fields "user ID" (int type), "username" (varchar type), "registration date" (date type), the system will create the table structure according to the information. Then, the system parses the data table default value node to set the default value of the field, for example, if the "registration date" field does not provide a value, the system will automatically fill in the current date to ensure the integrity and consistency of the data. Through the above steps, the system successfully creates the database file and table structure, and specifies appropriate default values for the fields, ensuring that the database subsystem functions normally and the data is complete.

[0024] Step S122, create a database table in the database file according to the database table node, and insert default values into the database table according to the data table default value node, to generate the first database subsystem. Specifically, according to the database table node in the configuration file, a corresponding database table is automatically generated in the created database file, and the table structure information includes the table name, field name, field type, etc. For example, if the configuration file defines a table named "users" containing "id", "name" and "email" fields, the system will create the table in the database according to this information. Then, the system automatically inserts the initial data of the table according to the data table default value node in the configuration file. The default value ensures that the database table contains the necessary initial data when it is created, thereby improving the startup efficiency of the system. Through the above process, the system realizes automatic database initialization and data filling, reduces manual operation, and improves efficiency and data consistency.

[0025] Step S200, load the XML operation message, perform operation parsing on the XML operation message, and obtain operation parsing data. Specifically, in this scheme, first, the system will load the incoming XML operation message, which is usually sent by the client and contains database operation instructions to be executed. For example, the operation message may contain requests to insert, update or query a database table. The system will parse the XML message to obtain elements and attributes such as the name of the target database table, field name, operation type and related data. The parsing process involves extracting information from XML tags and converting it into an internal data structure suitable for system processing. For example, if the message requests to insert data, the system will extract the data table name, field name and field corresponding value (e.g. insert into the "users" table, field "name" "age", value "John" and "30"). Then, the system organizes all the operation data parsed into a structured data format, called operation parsing data, which contains all the details required to execute the corresponding operation. Next, these operation parsing data will serve as the basis for subsequent execution of SQL statements, directly affecting the execution logic and results of subsequent database operations. Through such operation parsing process, the system can efficiently extract all the information required for execution from the XML message, ensuring that the subsequent database operation can be accurately executed.

[0026] Step S300, perform feature item matching analysis on the operation parsing data, if the matching analysis result returns empty, generate a SQL operation statement according to the operation parsing data, call the API of the first database subsystem to execute the SQL operation statement, and return the execution result of the XML operation message. For example, Figure 4As shown, specifically, the XML operation message is first loaded and parsed to extract the operation data. The operation parsing data typically includes information such as the target database table, operation type, operation field, and corresponding value. The system processes the operation parsing data through feature item matching analysis to analyze its compatibility with the database table structure. For example, the system checks whether the data field matches the field in the database and whether the data type matches, etc. If the parsing data does not match the structure of the database table, the system returns an empty matching result; if there is a matching item, the system continues to the next step. Next, in the case where no matching feature item is found, the system generates appropriate operation instructions based on the operation parsing data. The operation instructions are automatically generated based on the information of the database table and field to execute the corresponding command for the database operation. Next, the system calls the API of the first database subsystem to execute these operation instructions to ensure that the data is correctly operated and the corresponding result is returned. After the operation is completed, the system generates an XML operation result message based on the database execution result and returns it to the client. The result may include the success or failure of the operation, the number of affected records, or other execution feedback to help the client understand the operation status and perform subsequent processing.

[0027] In a possible implementation, as Figure 5As shown, the operation analysis data is subjected to feature item matching analysis, and if the matching analysis result returns null, an SQL operation statement is generated based on the operation analysis data, an API of the first database subsystem is called to execute the SQL operation statement, and an execution result of the XML operation message is returned. Step S300 further includes step S310, and if the matching analysis result returns non-null, a second database subsystem is connected. The second database subsystem uses a function in a third-party plug-in library to perform data processing on the XML operation message by calling dlopen. Specifically, after the system performs feature item matching analysis on the operation analysis data, if the matching analysis result returns non-null, it indicates that the operation data has a certain consistency with the database table structure or the agreed format. The system will then establish a connection with the second database subsystem. The second database subsystem is usually used to process some special business logic or manage specific types of data, such as some complex calculations or special business requirements. On this basis, the second database subsystem will load and link the third-party plug-in library by calling the dlopen function. The plug-in library contains some predefined processing functions that can be dynamically loaded into the system for data processing at runtime. For example, the plug-in library can provide some complex calculation functions or external data format conversion functions, which are designed to handle tasks that cannot be directly completed through regular database operations. After loading the plug-in, the second database subsystem will use the function to process the data in the XML operation message. The processing process can include data format conversion, data verification, or calculation of business logic according to specific rules, such as dynamically calculating the price based on customer order information or filtering invalid data based on specific conditions. Finally, after the data processing is completed, the second database subsystem will decide how to continue data storage or transmission based on the processing result, ensuring that all data can be correctly stored or fed back to the user in accordance with business rules and operation requirements.

[0028] In a possible implementation, as Figure 5As shown, if the matching analysis result returns not empty as described in the figure, the second database subsystem is connected, the second database subsystem uses the function in the third-party plug-in library configured by the dlopen call to perform data processing on the XML operation message, and step S310 further includes step S311 of loading a second XML configuration file, the second XML configuration file being a special XML configuration file that needs to be processed by a third-party plug-in. Specifically, the second XML configuration file needs to be loaded first, which is different from the regular configuration file because it contains special operations that need to be processed by a third-party plug-in. The loading process ensures that the file path and format are correct, and reads the contents into memory for subsequent processing. When parsing the configuration file, the system reads the file line by line and converts the key nodes in it into an operable data structure, including operation items, action items, and plug-in information, etc. Plug-in information is particularly important, which usually includes the name of the dynamic library and the name of the plug-in function, indicating the plug-in that needs to be dynamically loaded. The system identifies which operations need to rely on external plug-ins to complete by parsing the plug-in information, such as image processing, complex data calculation, or custom conversion, etc. Next, the system dynamically loads the dynamic library of the plug-in by calling methods such as dlopen, and can call specific functions in the plug-in for data processing as needed at runtime. Finally, the system will determine the calling relationship of the plug-in function according to the parsed operation item and action item, ensuring that the plug-in can be correctly connected with the database operation, thereby expanding the function of the system and meeting the complex or special data processing needs in the business. Through the above-mentioned manner, the system can flexibly support complex business logic through plug-ins when performing database operations, while maintaining high scalability and customizability.

[0029] Step S312, wherein the second XML configuration file includes operation items, action items, and third-party plugin information, and the third-party plugin information includes plugin dynamic library name and plugin function name. Specifically, the content of the second XML configuration file includes operation items, action items, and third-party plugin information. In this file, the operation item defines the specific operation that needs to be performed, such as inserting, updating, or querying data in the database. The action item describes how the operation is performed, for example, whether a transaction needs to be opened, whether data verification is involved, etc. The third-party plugin information part contains the dynamic library name and plugin function name of the plugin, which specifies the external plugin that needs to be called when the operation is performed. The system first loads the specified dynamic library file according to this information, which is usually a DLL or.so file stored in a specific directory of the system. By using the system-provided loading function (such as dlopen), the library file of the plugin is dynamically loaded, ensuring that the plugin can be accessed correctly at runtime. After loading is completed, the system calls the corresponding function according to the plugin function name specified in the file to complete the task, such as complex data calculation, format conversion, or business logic processing. For example, a certain operation item may require complex financial calculations, and the system can execute the calculations by loading a plugin library that specializes in handling financial data, ensuring the accuracy and efficiency of data processing. In this way, the second XML configuration file not only improves the flexibility of the system, but also enables the system to dynamically expand support for new business logic or data processing requirements by modifying the configuration file or adding new plugins, without the need to make extensive changes to the core code of the system.

[0030] Step S313, according to the plug-in calling relationship of the second XML configuration file, a second database subsystem is created. Specifically, the system loads the second XML configuration file, which contains operation items, action items and plug-in information that need to be processed by third-party plug-ins. The plug-in information part includes the name of the plug-in dynamic library and the name of the plug-in function. The system then parses the plug-in calling relationship in the file, identifies and associates the plug-in and its function required by each operation item. For example, suppose the file defines that an operation item needs to call a plug-in library named "dataProcessor", and call a function named "processData" in the library. The system will dynamically load the corresponding plug-in library according to these configurations, using the dlopen function to load the dynamic library file of the plug-in. After loading, the system uses the dlsym function to obtain the address of the plug-in function and binds it to the operation flow. According to the parsed plug-in calling relationship, the system creates a second database subsystem, which can perform database operations dependent on the plug-in. For example, a certain operation item may require calling the "dataProcessor" plug-in to verify or convert data before performing the database insertion operation. After the plug-in function processing is completed, the returned data will affect the subsequent database operation. Since the plug-in calling of this scheme is dynamic, the system can load different plug-ins according to actual business requirements without modifying the original code, so that the system function can be flexibly adjusted when the business expands or requirements change, enhancing the scalability and customization ability of the system. For example, in some cases, if specific format conversion needs to be handled, the system can load different plug-in libraries to flexibly support multiple operations without rewriting the database operation code.

[0031] In a possible implementation, as shown in Figure 5 If the matching analysis result returns not empty, connect the second database subsystem, which uses the dlopen to call the function in the third-party plug-in library to process the XML operation message, step S310 further includes step S314, the second database subsystem analyzes the XML operation message to determine the operation object and the action type. Specifically, in the second database subsystem, after receiving the XML operation message, the system will parse the message to extract the key elements in the message. First, determine the operation object, which usually refers to the table, view or field in the database. For example, if the message contains user_data The system will identify that the user_data table is the target object of this operation, and all subsequent operations will be performed on this table. Then, the system will further analyze the action type in the message, which usually represents the type of database operation, such as insert (INSERT), update (UPDATE), delete (DELETE) or query (SELECT). For example, if the message contains<action>INSERT< / action> , it indicates that this operation is a data insertion operation, and the system will prepare to insert data; if the action type is <action>UPDATE< / action> , it indicates that the operation is to update data, and the system will perform corresponding data verification and update logic. According to the parsed operation object and action type, the system will select the corresponding database operation according to the predefined rules, and save the analysis result as an internal structure to support subsequent data processing. In addition, these analysis results may also be recorded as operation logs for subsequent audit or traceability.

[0032] Step S315, according to the operation object and action type, use the dlopen function to load the third-party plug-in library to obtain the function address. Specifically, the second database subsystem first analyzes the received XML operation message to determine the operation object and action type. For example, assuming that the message contains a database table name "customer_data" and an action type "update", the system will identify the operation object as the "customer_data" table and the action type as "update". According to this information, the system then determines whether to use third-party plug-ins to perform data processing tasks. If necessary, the system will call the dlopen function to dynamically load the relevant third-party plug-in library. This step enables the system to decide which plug-ins to load at runtime based on the operation object and action type, for example, if the action is "encryption", the system may load a plug-in library that handles data encryption. Then, use the dlsym function to get the address of the corresponding function from the plug-in library, and call the function in the plug-in through the address. For example, if the plug-in library has an encryption function named encrypt_data, the system will call this function to encrypt the data. After the plug-in function is executed, the system will return the result and perform subsequent database operations as needed, such as storing the encrypted data into the database. In this way, the system can flexibly load and use plug-ins according to real-time needs, implement extended and customized processing tasks, and does not need to modify the underlying database operation code, thereby enhancing the flexibility and scalability of the system.

[0033] Step S316, the function address is called to process the XML operation message. Specifically, the second database subsystem analyzes the XML operation message, and first determines the operation object and action type, and then determines which third-party plug-in to use for data processing according to the information. For example, assuming that the operation object is "user data" and the action type is "encryption", the system will load an encryption plug-in library and obtain the address of the encryption function through the dlopen function. Then, the system will call the obtained encryption function to pass the user data (such as user password) to be processed for encryption operation. After encryption is completed, the processing result is returned. In this way, the system can dynamically select and process plug-ins according to different XML operation messages, ensuring flexibility and scalability.

[0034] In a possible implementation, as shown in Figure 4 The operation analysis data is subjected to feature item matching analysis, and if the matching analysis result returns null, an SQL operation statement is generated according to the operation analysis data, an API of the first database subsystem is called to execute the SQL operation statement, and an execution result of the XML operation message is returned. Step S300 further includes step S320, in which the first database subsystem parses an action item and an operation item of the XML operation message according to the operation analysis data. Specifically, after receiving the XML operation message, the first database subsystem first parses the message to extract operation analysis data, mainly including the action item and the operation item. The action item represents the specific operation type to be performed by the database, for example, the "add" operation represents inserting a new record into the database table, the "delete" operation represents deleting a specific record from the table, the "modify" operation represents updating the data in the table, and the "query" operation represents retrieving data from the database. Next, the subsystem extracts the operation item from the message, which includes detailed information of the database operation, such as the table name, field name, and field corresponding value to be operated. For example, when performing the "add" operation, the operation item can contain the inserted field name and corresponding value; when performing the "query" operation, the operation item can include the query condition and the required returned field. By analyzing these data, the first database subsystem can accurately determine the operation object and operation type to be performed, and provide necessary information for the subsequent SQL statement generation process. The core of this process is to accurately understand and perform the corresponding operation of the database by parsing the action item and the operation item in the operation message.

[0035] Step S330, determine the operation type according to the action item, and find the data table item and operation parameters corresponding to the operation item. Specifically, when processing the operation item, first, the system will determine the operation type according to the parsed action item. For example, if the action item is "INSERT", the system will identify the operation as "add" type, if it is "DELETE", it is "delete" type, if it is "UPDATE", it is "modify" type, and if it is "SELECT", it is "query" type. Next, the system will find the data table item corresponding to the operation item according to the information in the operation item. For example, if the operation item contains the table name "User", the system will perform subsequent operations on the "User" table. If the operation item does not explicitly specify the table name, the system will infer according to the context information or default rules, and may select the default table in the system for operation. Then, the system will extract the operation parameters, which are the detailed information required to perform specific database operations. For example, in the "add" operation, the operation parameters may include field names and corresponding values, such as field "username" corresponding to value "Alice"; in the "delete" operation, the operation parameters may be the deletion condition, such as field "user_id" value 123; in the "modify" operation, the operation parameters include fields and their new values, such as field "email" updated to "new_email@example.com"; and in the "query" operation, the operation parameters may be the filtering condition and the required returned fields, such as filtering condition "user_id equal to 456" and returning fields "username" and "email". If the table name or parameters are missing in the operation item, the system will take default processing or return an error prompt, ensuring that each operation has complete context and correct parameters, thus ensuring the accuracy and consistency of database operations.

[0036] Step S340: Generate an SQL operation statement based on the operation type, data table entries, and operation parameters. Specifically, in generating the database operation statement, the system first determines the operation type based on the action items (e.g., insert, delete, update, or query) in the operation parsing data. For example, if the operation type is "insert," the system identifies that data needs to be inserted into a certain data table and extracts the relevant fields and values ​​from the operation parameters. If the operation type is "delete," the system identifies which data table needs to be deleted from based on the conditions. Next, the system identifies the specific fields to be processed and their corresponding values ​​based on the data table indicated by the operation item and the operation parameters. For example, in an insert operation, the system needs to determine which fields need to be filled with values ​​and which fields can use default values; in an update operation, the system checks the fields to be modified and the new values, and generates the corresponding modification instructions. If the operation is a query, the system identifies the fields to be queried and the filter conditions. Through comprehensive analysis of the operation type, data table entries, and operation parameters, the system can dynamically construct an operation statement that conforms to database specifications, ensuring the correct processing and storage of data.

[0037] This application embodiment loads and parses a first XML configuration file that does not require third-party plugins to create a first database subsystem; loads and parses XML operation messages to extract operation parsing data; performs feature matching analysis on the parsed data, and if no matching result is found, generates an SQL statement, executes the operation through the API of the first database subsystem, and returns the execution result. This achieves the technical effect of simplifying the interaction process between XML data and the database, reducing development dependencies, and improving development efficiency by encapsulating XML data parsing and database operations into a general interface.

[0038] In the above text, refer to Figure 1 A database operation method based on XML according to an embodiment of the present invention has been described in detail. Next, reference will be made to... Figure 2 This invention describes an XML-based database operating system according to an embodiment of the present invention.

[0039] An XML-based database operating system according to an embodiment of the present invention solves the technical problems of low development efficiency caused by the complexity and strong dependency of the XML data-database interaction process in the prior art. By encapsulating XML data parsing and database operations into a general interface, it achieves the technical effects of simplifying the XML data-database interaction process, reducing development dependencies, and improving development efficiency. An XML-based database operating system includes: a first XML configuration file loading module 10, an operation message loading module 20, and an operation statement generation module 30.

[0040] The first XML configuration file loading module 10 is configured to load a first XML configuration file, parse the first XML configuration file to create a first database subsystem, wherein the first XML configuration file is an XML configuration file that does not need to be processed by a third-party plug-in.

[0041] The operation message loading module 20 is configured to load an XML operation message, parse the XML operation message to obtain operation analysis data.

[0042] The operation statement generation module 30 is configured to perform feature item matching analysis on the operation analysis data, generate an SQL operation statement according to the operation analysis data if the matching analysis result is empty, call an API of the first database subsystem to execute the SQL operation statement, and return an execution result of the XML operation message.

[0043] In the following, the specific configuration of the first XML configuration file loading module 10 will be described in detail. As described above, the first XML configuration file loading module 10 is configured to load a first XML configuration file, parse the first XML configuration file to create a first database subsystem, wherein the first XML configuration file is an XML configuration file that does not need to be processed by a third-party plug-in. The first XML configuration file loading module 10 further includes a database node obtaining unit configured to parse the first XML configuration file to obtain a database file node, a database table node, and a data table default value node; and a first database subsystem creating unit configured to create the first database subsystem according to the database file node, the database table node, and the data table default value node.

[0044] The first database subsystem creating unit further includes a database file creating subunit configured to determine whether the database file node exists, and create a corresponding database file if the database file node exists, and a default value inserting subunit configured to create a database table in the database file according to the database table node, and insert a default value into the database table according to the data table default value node to generate the first database subsystem.

[0045] In the following, the specific configuration of the operation statement generation module 30 will be described in detail. As described above, the operation analysis data is subjected to feature item matching analysis, and if the matching analysis result returns null, an SQL operation statement is generated according to the operation analysis data, the API of the first database subsystem is called to execute the SQL operation statement, the execution result of the XML operation message is returned, and the operation statement generation module 30 further comprises a second database subsystem connection unit, which is configured to connect the second database subsystem if the matching analysis result returns non-null, and the second database subsystem uses the function in the third-party plug-in library configured by dlopen to process the XML operation message.

[0046] If the matching analysis result returns non-null, the second database subsystem is connected, and the second database subsystem uses the function in the third-party plug-in library configured by dlopen to process the XML operation message. The second database subsystem connection unit further comprises a second XML configuration file loading subunit, which is configured to load a second XML configuration file, the second XML configuration file being a special XML configuration file that needs to be processed by a third-party plug-in; a configuration file composition subunit, which is configured to wherein the second XML configuration file comprises an operation item, an action item, and third-party plug-in information, the third-party plug-in information comprising a plug-in dynamic library name and a plug-in function name; and a second database subsystem creation subunit, which is configured to create a second database subsystem according to the plug-in calling relationship of the second XML configuration file.

[0047] The operation statement generation module 30 further comprises an operation message analysis unit, which is configured to analyze the action item and the operation item of the XML operation message according to the operation analysis data; an operation type determination unit, which is configured to determine the operation type according to the action item, and to find the data table item and the operation parameter corresponding to the operation item; and an SQL operation statement generation unit, which is configured to generate an SQL operation statement according to the operation type, the data table item, and the operation parameter.

[0048] The second database subsystem connection unit further comprises: an operation object determination subunit, configured to analyze the XML operation message by the second database subsystem, and determine an operation object and an action type; a function address acquisition subunit, configured to acquire a function address by loading a third-party plug-in library using a dlopen function according to the operation object and the action type; and a data processing subunit, configured to perform data processing on the XML operation message by calling a function according to the function address.

[0049] The XML-based database operation system provided by the embodiment can execute the XML-based database operation method provided by any of the embodiments, and has the corresponding function modules and beneficial effects.

[0050] Although the present application makes various references to certain modules in the system according to the embodiments of the present application, however, any number of different modules can be used and run on the user terminal and / or server, and each unit and module is only divided according to the functional logic, but is not limited to the above division, as long as the corresponding functions can be realized; in addition, the specific names of each functional unit are only for easy mutual differentiation, and do not limit the protection scope of the present application.

[0051] The above specific embodiments do not constitute a limitation on the protection scope of the present application. Those skilled in the art should understand that various modifications, combinations and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims

1. A database operation method based on XML, characterized in that, The method includes: Load the first XML configuration file, parse the first XML configuration file to create the first database subsystem, wherein the first XML configuration file is an XML configuration file that does not require processing by third-party plugins; Load the XML operation message, parse the XML operation message, and obtain the operation parsing data; The operation parsing data is subjected to feature matching analysis. If the matching analysis result is empty, an SQL operation statement is generated based on the operation parsing data. The API of the first database subsystem is called to execute the SQL operation statement, and the execution result of the XML operation message is returned. The feature matching analysis of the operation parsing data also includes: If the matching analysis result is not empty, connect to the second database subsystem. The second database subsystem uses dlopen to call the function in the configuration third-party plugin library to process the XML operation message. The methods for creating the second database subsystem include: Load the second XML configuration file, which is a special XML configuration file that requires processing by a third-party plugin; The second XML configuration file includes operation items, action items, and third-party plugin information, wherein the third-party plugin information includes the plugin dynamic library name and the plugin function name; Based on the plugin call relationships in the second XML configuration file, create a second database subsystem; The method for parsing the first XML configuration file to create the first database subsystem includes: The first XML configuration file is parsed to obtain the database file node, database table node, and data table default value node; The method for creating a first database subsystem based on the database file node, database table node, and data table default value node includes: Determine if the database file node exists; if it exists, create the corresponding database file; and The database table is created in the database file according to the database table node, and default values ​​are inserted into the database table according to the data table default value node to generate the first database subsystem; The method for generating SQL operation statements based on the parsed data includes: The first database subsystem parses the action items and operation items of the XML operation message according to the operation parsing data; The operation type is determined based on the action item, and the corresponding data table item and operation parameters are found. Based on the operation type, data table items, and operation parameters, generate SQL operation statements.

2. The method as described in claim 1, characterized in that, The second database subsystem uses dlopen to call functions in a third-party plugin library to process the XML operation messages. The method includes: The second database subsystem analyzes the XML operation message to determine the operation object and action type; Based on the operation object and action type, the dlopen function is used to load the third-party plugin library and obtain the function address; The XML operation message is processed by calling a function based on its address.

3. An XML-based database operating system, characterized in that, The system is used to implement the XML-based database operation method according to any one of claims 1-2, the system comprising: The first XML configuration file loading module is used to load the first XML configuration file, parse the first XML configuration file to create the first database subsystem, wherein the first XML configuration file is an XML configuration file that does not require processing by third-party plugins; An operation message loading module is used to load XML operation messages, parse the XML operation messages, and obtain operation parsing data. An operation statement generation module is used to perform feature matching analysis on the operation parsing data. If the matching analysis result is empty, an SQL operation statement is generated based on the operation parsing data, the API of the first database subsystem is called to execute the SQL operation statement, and the execution result of the XML operation message is returned.

Images