XML-based database operation method and system

Abstract

The invention discloses an XML-based database operation method and system, and relates to the technical field of computers.The method comprises the steps that a first XML configuration file without a third-party plug-in is loaded and analyzed, and a first database subsystem is created; loading and analyzing the XML operation message, and extracting operation analysis data; and performing feature matching analysis on the analysis data, if no matching result exists, generating an SQL statement, executing an operation through an API of the first database subsystem, and returning an execution result. The technical problems that in the prior art, the XML data and database interaction process is complex, dependency is high, and development efficiency is low are solved, and the technical effects that the XML data and database interaction process is simplified, development dependency is reduced, and development efficiency is improved are achieved by packaging XML data analysis and database operation into a universal interface.

Description

Technical Field

[0001] This application relates to the field of computer technology, and particularly to a method and system for database operation based on XML. Background Art

[0002] As XML has become the mainstream format for data transmission between clients and servers, its application in database interaction has become increasingly widespread. However, in the prior art, the process of processing the interaction between XML data and databases is complex. Usually, it is necessary to pre-convert XML-formatted data into binary structures and write specific operation codes for different databases, which poses relatively high requirements for developers. In addition, when the system adapts to different databases or processes new XML message formats, it often requires modifying the underlying code, increasing the development and maintenance costs and making it difficult to meet the dynamically changing business requirements. To address the above problems, there is an urgent need in the industry for a technical solution that can simplify the XML data processing flow and effectively reduce the system complexity.

[0003] In the current related technologies, there are technical problems such as the complex and highly dependent process of XML data and database interaction, resulting in low development efficiency. Summary of the Invention

[0004] This application solves the technical problems in the prior art that the process of XML data and database interaction is complex and highly dependent, resulting in low development efficiency, by providing a method and system for database operation based on XML.

[0005] This application provides a method for database operation based on XML, including:

[0006] Loading a first XML configuration file, parsing the first XML configuration file to create a first database subsystem, where the first XML configuration file is an XML configuration file that does not require third-party plugins for processing; loading an XML operation message, performing operation parsing on the XML operation message to obtain operation parsing data; performing feature item matching analysis on the operation parsing data, if the matching analysis result returns empty, generating an SQL operation statement according to the operation parsing 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] This application provides a database operation system based on XML, including:

[0008] 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, where the first XML configuration file is an XML configuration file that does not require third-party plugins for processing; the operation message loading module is used to load the XML operation message, perform operation parsing on the XML operation message to obtain operation parsing data; the operation statement generation module is used to perform feature item matching analysis on the operation parsing data. If the matching analysis result returns empty, generate an 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.

[0009] It is proposed to use a database operation method and system based on XML in this application. First, load and parse the first XML configuration file without third-party plugins to create the first database subsystem; load and parse the XML operation message to extract operation parsing data; perform feature matching analysis on the parsed data. If there is no matching result, generate an SQL statement, execute the operation through the API of the first database subsystem, and return the execution result, achieving the technical effect of simplifying the XML data and database interaction process, reducing development dependencies, and improving development efficiency by encapsulating XML data parsing and database operations into a general interface. Description of the Drawings

[0010] Figure 1 It is a schematic flowchart of a database operation method based on XML provided by an embodiment of this application;

[0011] Figure 2 It is a schematic structural diagram of a database operation system based on XML provided by an embodiment of this application;

[0012] Figure 3 It is a schematic flowchart of creating the first database subsystem of a database operation method based on XML provided by an embodiment of this application;

[0013] Figure 4 It is a schematic flowchart of the operation process of the first database subsystem of a database operation method based on XML provided by an embodiment of this application;

[0014] Figure 5 It is a schematic flowchart of the data processing process of the second database subsystem of a database operation method based on XML provided by an embodiment of this application.

[0015] Description of the reference numerals: The first XML configuration file loading module 10, the operation message loading module 20, the operation statement generation module 30. Detailed Implementation Modes

[0016] The above description is only an overview of the technical solution of this application. In order to understand the technical means of this application more clearly, it can be implemented according to the content of the specification. In order to make the above and other purposes, features and advantages of this application more obvious and understandable, the following specifically gives the detailed implementation modes of this application.

[0017] In order to make the purpose, technical solution and advantages of this application clearer, the following will further describe this application in detail with reference to the accompanying drawings. The described embodiments should not be regarded as limitations of this application. All other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this application.

[0018] In the following description, "some embodiments" are involved, which describe a subset of all possible embodiments. However, it can be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict. The terms "first\second" involved are only used to distinguish similar objects and do not represent a specific order for the objects. The terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or server comprising a series of steps or units does not necessarily have to be limited to those steps or units clearly listed, but may include other steps or modules 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 commonly understood by those skilled in the technical field to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application.

[0019] An embodiment of this application provides a database operation method based on XML, as Figure 1 shown. The method includes:

[0020] Step S100, load a first XML configuration file, and parse the first XML configuration file to create a first database subsystem, where the first XML configuration file is an XML configuration file that does not require a third-party plugin for processing. As 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 structures, field definitions, etc. After loading the file, the system parses the XML file through a built-in parser. The parsing process does not rely on any third-party plugins, reducing external dependencies and making the system more efficient and easier to maintain. During the parsing process, the system reads the XML file item by item, extracts key information, such as the location of the database file, the name of the table, the type and constraints of the fields, etc., to ensure that the configuration can be correctly recognized. Then, based on the parsed data, the system automatically constructs the first database subsystem, including generating the database file, creating data tables, and configuring the table structure according to the field definitions and constraints. The entire process is completely based on the XML configuration file and is achieved without using any additional plugins, thus 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 requirements.

[0021] In one possible implementation, such as Figure 3As shown, the first XML configuration file is loaded and parsed to create the first database subsystem. The first XML configuration file is an XML configuration file that does not require third-party plugins for processing. Step S100 further includes step S110 of parsing the first XML configuration file to obtain database file nodes, database table nodes, and data table default value nodes. Specifically, first, the first XML configuration file is loaded and parsed to extract database file nodes, database table nodes, and data table default value nodes for creating the database subsystem. Specifically, first, by parsing the database file nodes, the system can obtain information such as the path and storage location of the database file, and then determine whether a new database file needs to be created. If the file does not exist, the system will automatically create this file according to the configuration to ensure that the database file is correctly initialized and in the specified location. Next, the system parses the database table nodes to extract the table structure information in the database, including the name, fields, and field types of each table. For example, it may include a table named "User" with fields such as "User ID", "User Name", and "Registration Date", and each field may correspond to different data types such as integer, string, or date type. By obtaining the information, the system can create corresponding structures for each table according to the requirements of the configuration file to ensure that the database design meets the expectations. Finally, the system also parses the data table default value nodes to extract the default value information for 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, and in this case, the system will use the default values defined in the configuration file to fill the fields to ensure 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 the field value. These steps ensure that the creation and initialization of the database subsystem not only meet the design requirements but also can handle various situations of data missing.

[0022] Step S120: Create a first database subsystem based on the database file node, database table node, and data table default value node. Specifically, in the process of creating the first database subsystem, it is first necessary 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. If there is no corresponding database file in this path, the system will automatically create a new file. Next, the system parses the database table node, which defines each data table to be created and its field information, including field names, types, etc. For example, if the node defines a "user" table and its fields "user ID" (int type), "user name" (varchar type), and "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 and sets the default values of the fields based on this node. 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 assigns appropriate default values to the fields, ensuring the normal function and data integrity of the database subsystem.

[0023] In a possible implementation, as Figure 3 shown, to create a first database subsystem based on the database file node, database table node, and data table default value node, step S120 further includes step S121: Determine whether the database file node exists. If it exists, create the corresponding database file, and. Specifically, the system parses the database file node from the XML configuration file, which contains necessary information about the database file, such as file path, file name, etc. Next, the system will determine whether the database file node exists. Specifically, it checks whether the path or file name provided in the node points to an actually existing file. This determination is completed through the operating system's file system API. For example, the system will use a file path checking function to determine whether there is already a file at the specified path. If the file already exists, the system will directly skip the step of creating the file and continue with the subsequent database table structure creation and data insertion operations. For example, if the database file node points to the path / data / db / mydb.db, the system will check whether there is already a database file named mydb.db at this path. If it exists, the system will use this file to continue the processing; if the file does not exist, the system will automatically create a new database file at the specified path according to the information provided in the configuration file, such as the path and file type. In this way, the system ensures the correct management of the database file and avoids the situation of duplicate creation or data loss.

[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. The table structure information includes the table name, field names, and field types, etc. For example, if a table named "users" is defined in the configuration file, including fields "id", "name", and "email", the system will create this 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 values ensure that the database table already contains the necessary initial data when it is created, thus improving the startup efficiency of the system. Through the above process, the system realizes automated database initialization and data filling, reduces manual operations, 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 solution, first, the system loads the incoming XML operation message. The message is usually sent by the client and contains the database operation instructions to be executed. For example, the operation message may contain requests to insert, update, or query a database table. The system parses this XML-formatted message to obtain the elements and attributes in it, such as the name of the target database table, field names, operation types, and related data. The parsing process involves extracting the information in the 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 name of the data table to be inserted, field names, and the corresponding values of the fields (for example, insert into the "users" table, fields are "name" and "age", and values are "John" and "30"). Then, the system organizes all the parsed operation data into a structured data format called operation parsing data. These data contain all the details required to execute the corresponding operation. Next, these operation parsing data will serve as the basis for executing subsequent SQL statements and directly affect the execution logic and results of subsequent database operations. Through such an operation parsing process, the system can efficiently extract all the information required for execution from the XML message, ensuring that subsequent database operations can be executed accurately.

[0026] Step S300: Perform feature item matching analysis on the operation parsing data. If the matching analysis result returns empty, generate an 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. As Figure 4As shown, specifically, first, the XML operation message is loaded and parsed to extract the operation data therein. The operation parsed data usually contains information such as the target database table, operation type, operation fields and their corresponding values, etc. The system will process the operation parsed data through feature item matching analysis to analyze its compatibility with the database table structure. For example, the system checks whether the data fields match the fields in the database and whether the data types match, etc. If the parsed data does not match the structure of the database table, the system will return an empty matching result; if there are matching items, the system will continue with the next step. Next, in the case where no matching feature items are found, the system will generate appropriate operation instructions based on the operation parsed data. The operation instructions are automatically generated based on the information of the database table and fields to generate the corresponding commands for performing database operations. 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 results are returned. After the operation is completed, the system will generate an XML operation result message based on the database execution result and return it to the client. The result may include whether the operation is successful, 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, such as Figure 5As shown, perform feature item matching analysis on the operation parsing data. If the matching analysis result returns empty, generate an SQL operation statement based on 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. Step S300 further includes step S310. If the matching analysis result returns non-empty, connect to the second database subsystem. The second database subsystem uses dlopen to call functions in the configured third-party plugin library to process the data in the XML operation message. Specifically, after the system performs feature item matching analysis on the operation parsing data, if the matching analysis result returns non-empty, it indicates that the operation data has a certain consistency with the database table structure or the agreed format. Next, the system will establish a connection with the second database subsystem. This second database subsystem is usually used to handle some special business logics 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 plugin library by calling the dlopen function. The plugin library contains some predefined processing functions that can be dynamically loaded into the system at runtime for data processing. For example, the plugin library may provide some complex calculation functions or functions for converting external data formats, aiming to handle tasks that cannot be directly completed through regular database operations. After loading the plugin, the second database subsystem will use the functions to process the data in the XML operation message. The processing process may include data format conversion, data verification, or calculating business logics according to specific rules, such as dynamically calculating prices based on customers' order information or filtering invalid data according to specific conditions. Finally, after the data processing is completed, the second database subsystem will decide how to continue data storage or transmission according to the processing result, ensuring that all data can be correctly stored or fed back to the user under the condition of conforming to business rules and operation requirements.

[0028] In a possible implementation, such as Figure 5As shown, if the returned matching analysis result is not empty, connect to the second database subsystem. The second database subsystem uses dlopen to call functions in the configured third-party plugin library to process the XML operation message. Step S310 further includes step S311 of loading a second XML configuration file, which is a special XML configuration file that requires third-party plugin processing. Specifically, first, the second XML configuration file needs to be loaded. This file is different from the regular configuration file because it contains special operations that require third-party plugin processing. The loading process ensures that the file path and format are correct and reads its content into memory for subsequent processing. When parsing this configuration file, the system reads the file line by line and converts the key nodes therein into manipulable data structures, including operation items, action items, and plugin information, etc. The plugin information is particularly crucial. It usually includes the name of the dynamic library and the name of the plugin function, indicating the plugin that needs to be dynamically loaded. By parsing the plugin information, the system can identify which operations need to rely on external plugins to complete, such as image processing, complex data calculations, or custom conversions, etc. Next, the system dynamically loads the dynamic library of the plugin by calling methods such as dlopen, and can call specific functions in the plugin for data processing as needed at runtime. Finally, the system will determine the call relationship of the plugin functions based on the parsed operation items and action items, ensuring that the plugin can be correctly docked with the database operation, thereby expanding the system's functions and meeting the complex or special data processing requirements in the business. Through the above method, when the system performs database operations, it can flexibly support complex business logics through plugins while maintaining high scalability and customizability.

[0029] Step S312, where the second XML configuration file includes operation items, action items, and third-party plugin information. The third-party plugin information includes the plugin dynamic library name and the 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 items define the specific operations to be performed, such as inserting, updating, or querying data in a database. The action items describe how the operation is to be executed, for example, whether a transaction needs to be started, whether data validation is involved, etc. The third-party plugin information section contains the plugin's dynamic library name and the plugin function name, specifying the external plugin to be called when performing the operation. The system first loads the specified dynamic library files based on this information. These files are usually DLL or.so files stored in a specific directory of the system. By using the loading functions provided by the system (such as dlopen), the library file of the plugin is dynamically loaded to ensure that the plugin can be correctly accessed during runtime. After the loading is completed, the system calls the corresponding function according to the plugin function name specified in the file to complete tasks, such as performing complex data calculations, format conversions, or business logic processing. For example, a certain operation item may require complex financial calculations. The system executes this calculation by loading a plugin library dedicated to processing financial data to ensure 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 to support new business logics or data processing requirements, simply by modifying the configuration file or adding new plugins without making a large number of changes to the core code of the system.

[0030] Step S313: Create a second database subsystem according to the plug-in call relationship in the second XML configuration file. 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 section includes the name of the plug-in dynamic library and the name of the plug-in function. The system then parses the plug-in call relationship in the file, identifies and associates the plug-ins and their functions required for each operation item. For example, assume that the file defines an operation item that needs to call a plug-in library named "dataProcessor" and call a function named "processData" in this library. The system will dynamically load the corresponding plug-in library according to these configurations, and use 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 bind it to the operation process. According to the parsed plug-in call relationship, the system creates a second database subsystem so that it can execute database operations that depend on plug-ins. For example, an operation item may require calling the "dataProcessor" plug-in to verify or transform data before performing a database insert operation. After the plug-in function finishes processing, the returned data will affect subsequent database operations. Since the plug-in calls in this solution are dynamic, the system can load different plug-ins according to actual business needs without modifying the original code. In this way, when the business expands or the requirements change, the system functions can be flexibly adjusted, enhancing the scalability and customization ability of the system. For example, in some cases, if specific format conversion needs to be processed, 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 Figure 5 shown, if the matching analysis result returns non-empty, connect to the second database subsystem. The second database subsystem uses dlopen to call functions in the configured 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 action type. Specifically, in the second database subsystem, after receiving the XML operation message, the system will parse the message and extract each key element in the message. First, it is to determine the operation object. The operation object usually refers to a 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. The action type 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 an insert data 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 execute the 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 auditing or tracing purposes.

[0032] Step S315, according to the operation object and action type, use the dlopen function to load the third-party plugin 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, assume that the message contains the database table name "customer_data" and the action type "update", then the system will identify the operation object as the "customer_data" table and the action type as "update". Based on this information, the system then determines whether a third-party plugin is needed to perform the data processing task. If needed, the system will call the dlopen function to dynamically load the relevant third-party plugin library. This step enables the system to decide which plugins to load at runtime according to the operation object and action type. For example, if the action is "encryption", the system may load a plugin library for processing data encryption. Then, use the dlsym function to obtain the address of the corresponding function from the plugin library, and call the function in the plugin through this address. For example, if there is an encryption function named encrypt_data in the plugin library, the system will call this function to encrypt the data. After the plugin function is executed, the system will return the result and perform subsequent database operations as needed, such as storing the encrypted data in the database. In this way, the system can flexibly load and use plugins according to real-time needs, realize extended and customized processing tasks, without modifying the underlying database operation code, thus enhancing the flexibility and scalability of the system.

[0033] Step S316: Call a function according to the function address to process the data of the XML operation message. Specifically, after analyzing the XML operation message, the second database subsystem first determines the operation object and the action type, and then decides which third-party plugin to use for data processing based on this information. For example, assume the operation object is "user data" and the action type is "encryption". At this time, the system will load an encryption plugin library and obtain the address of the encryption function through the dlopen function. Then, the system will call the obtained encryption function and pass the user data to be processed (such as the user password) for encryption operation. After the encryption is completed, the processing result is returned. In this way, the system can dynamically select plugins and process them according to different XML operation messages, ensuring flexibility and scalability.

[0034] In a possible implementation, as Figure 4 shown, perform feature item matching analysis on the operation parsing data. If the matching analysis result returns empty, generate an 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. Step S300 further includes step S320. The first database subsystem parses the action item and the operation item of the XML operation message according to the operation parsing data. Specifically, after receiving the XML operation message, the first database subsystem first parses the message and extracts the operation parsing data therein, mainly including the action item and the operation item. The action item represents the specific operation type that the database needs to execute. 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 items from the message. These operation items include the detailed information of the database operation, such as the table name, field name, and the value corresponding to the field that need to be operated. For example, when performing the "add" operation, the operation item may contain the inserted field name and the corresponding value; when performing the "query" operation, the operation item may include the query condition and the fields to be returned. By parsing these data, the first database subsystem can accurately determine the operation object and operation type to be executed, and provide the necessary information for the subsequent SQL statement generation process. The core of this process is to accurately understand and execute the corresponding database operations by parsing the action item and the operation item in the operation message.

[0035] Step S330: Determine the operation type according to the operation item, and search for the corresponding data table item and operation parameters of the operation item. Specifically, when processing the operation item, first, the system determines the operation type according to the parsed operation item. For example, if the operation item is "INSERT", the system will identify the operation as an "add" type; if it is "DELETE", it is a "delete" type; if it is "UPDATE", it is a "modify" type; if it is "SELECT", it is a "query" type. Next, the system searches for the corresponding data table 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 infers based on the context information or default rules and may select the default table in the system for operation. After that, the system extracts the operation parameters, which are the detailed information required to execute the specific database operation. For example, in the "add" operation, the operation parameters may include the field name and the corresponding value, such as the field "username" corresponding to the value "Alice"; in the "delete" operation, the operation parameters may be the deletion condition, such as the field "user_id" with the value 123; in the "modify" operation, the operation parameters include the field and its new value, such as the field "email" updated to "new_email@example.com"; and in the "query" operation, the operation parameters may be the filtering condition and the fields to be returned. For example, the filtering condition is "user_id equals 456", and the fields "username" and "email" are returned. If the table name or parameter is missing in the operation item, the system will take default processing or return an error prompt to ensure that each operation is executed with complete context and correct parameters, thus ensuring the accuracy and consistency of database operations.

[0036] Step S340: Generate an SQL operation statement according to the operation type, data table items, and operation parameters. Specifically, during the process of generating the database operation statement, the system first determines the operation type based on the action item in the operation parsing data (e.g., insert, delete, update, or query). For example, if the operation type is "insert", the system will identify that data needs to be inserted into a certain data table and extract the relevant fields and values from the operation parameters. If the operation type is "delete", the system will identify which data table to delete data from according to the conditions. Then, the system will identify 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 will check the fields to be modified and the new values and generate corresponding modification instructions. If the operation is a query, the system will identify the query fields and filtering conditions. Through the comprehensive analysis of the operation type, data table items, and operation parameters, the system can dynamically construct an operation statement that conforms to the database specification to ensure the correct processing and storage of data.

[0037] The embodiment of the present application adopts loading and parsing a first XML configuration file without a third-party plugin to create a first database subsystem; loading and parsing an XML operation message to extract operation parsing data; performing feature matching analysis on the parsing data. If there is no matching result, an SQL statement is generated, and the operation is executed through the API of the first database subsystem, and the execution result is returned, achieving the technical effect of simplifying the XML data and database interaction process, reducing development dependencies, and improving development efficiency by encapsulating XML data parsing and database operations into a general interface.

[0038] In the above text, reference is made to Figure 1 which describes in detail a method for XML-based database operations according to an embodiment of the present invention. Next, a database operating system based on XML according to an embodiment of the present invention will be described with reference to Figure 2 which describes a database operating system based on XML according to an embodiment of the present invention.

[0039] A database operating system based on XML according to an embodiment of the present invention is used to solve the technical problem in the prior art that the interaction process between XML data and the database is complex and highly dependent, resulting in low development efficiency. By encapsulating XML data parsing and database operations into a general interface, the technical effects of simplifying the XML data and database interaction process, reducing development dependencies, and improving development efficiency are achieved. A database operating system based on XML includes: a first XML configuration file loading module 10, an operation message loading module 20, and an operation statement generating module 30.

[0040] The first XML configuration file loading module 10 is used to load the 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 require a third-party plugin for processing.

[0041] The operation message loading module 20 is used to load an XML operation message, perform operation parsing on the XML operation message, and obtain operation parsing data.

[0042] The operation statement generation module 30 is used to perform feature item matching analysis on the operation parsing data. If the matching analysis result returns empty, generate an 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.

[0043] Next, the specific configuration of the first XML configuration file loading module 10 will be described in detail. As described above, load the 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 require a third-party plugin for processing. The first XML configuration file loading module 10 further includes: a database node acquisition unit, which is used to parse the first XML configuration file to obtain a database file node, a database table node, and a data table default value node; a first database subsystem creation unit, which is used to create a first database subsystem according to the database file node, the database table node, and the data table default value node.

[0044] Among them, to create a first database subsystem according to the database file node, the database table node, and the data table default value node, the first database subsystem creation unit further includes: a database file creation subunit, which is used to determine whether the database file node exists, and if it exists, create a corresponding database file; and a default value insertion subunit, which is used to 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.

[0045] Next, the specific configuration of the operation statement generation module 30 will be described in detail. As described above, for the operation parsing data, a feature item matching analysis is performed. If the matching analysis result returns empty, an SQL operation statement is generated based on the operation parsing data, and 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 operation statement generation module 30 further includes: a second database subsystem connection unit, which is used to connect to the second database subsystem if the matching analysis result does not return empty. The second database subsystem uses dlopen to call functions in the configured third-party plugin library to process the XML operation message.

[0046] Among them, if the matching analysis result does not return empty, connect to the second database subsystem. The second database subsystem uses dlopen to call functions in the configured third-party plugin library to process the XML operation message. The second database subsystem connection unit further includes: a second XML configuration file loading subunit, which is used to load a second XML configuration file. The second XML configuration file is a special XML configuration file that requires third-party plugin processing; a configuration file composition subunit, which is used to, among them, the second XML configuration file includes operation items, action items, and third-party plugin information. The third-party plugin information includes the plugin dynamic library name and the plugin function name; a second database subsystem creation subunit, which is used to create a second database subsystem according to the plugin call relationship of the second XML configuration file.

[0047] Among them, the operation statement generation module 30 further includes: an operation message parsing unit, which is used for the first database subsystem to parse the action item and operation item of the XML operation message according to the operation parsing data; an operation type determination unit, which is used to determine the operation type according to the action item, and find the data table item and operation parameters corresponding to the operation item; an SQL operation statement generation unit, which is used to generate an SQL operation statement according to the operation type, data table item, and operation parameters.

[0048] Among them, the second database subsystem connection unit further includes: an operation object determination subunit, which is used for the second database subsystem to analyze the XML operation message to determine the operation object and the action type; a function address acquisition subunit, which is used to load a third-party plugin library using the dlopen function according to the operation object and the action type to obtain the function address; a data processing subunit, which is used to call a function according to the function address to perform data processing on the XML operation message.

[0049] The database operating system based on XML provided by the embodiments of the present invention can execute the database operation method based on XML provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[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 the server. The included units and modules are only divided according to the functional logic, but are not limited to the above division, as long as the corresponding functions can be realized; in addition, the specific names of the functional units are only for the convenience of mutual distinction and do not limit the protection scope of the present invention.

[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 principle of the present application shall be included within the protection scope of the present application.

Claims

1. A database operation method based on XML, characterized in that: The method comprises: 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 require processing by a third-party plug-in; Loading an XML operation message, performing operation parsing on the XML operation message, and obtaining operation parsing data; Perform feature item matching analysis on the operation parsing data. If the matching analysis result is returned as null, generate an 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.

2. The method according to claim 1, characterized in that Performing feature item matching analysis on the operation parsing data also includes: If the matching analysis result is not returned as null, the second database subsystem is connected, and the second database subsystem uses dlopen to call a function in a configured third-party plug-in library to perform data processing on the XML operation message.

3. The method according to claim 2, characterized in that The method for creating the second database subsystem includes: Loading a second XML configuration file, where the second XML configuration file is a special XML configuration file that needs to be processed by a third-party plug-in; The second XML configuration file includes operation items, action items and third-party plug-in information, and the third-party plug-in information includes a plug-in dynamic library name and a plug-in function name; A second database subsystem is created according to the plug-in calling relationship of the second XML configuration file.

4. The method according to claim 1, characterized in that The first XML configuration file is parsed to create a first database subsystem, the method comprising: Parse the first XML configuration file to obtain a database file node, a database table node, and a data table default value node; A first database subsystem is created according to the database file node, the database table node and the data table default value node.

5. The method according to claim 4, characterized in that According to the database file node, the database table node and the data table default value node, a first database subsystem is created, the method comprising: Determine whether the database file node exists, and if so, create a corresponding database file; and A database table is created in the database file according to the database table node, and a default value is inserted into the database table according to the data table default value node, so as to generate the first database subsystem.

6. The method according to claim 1, characterized in that The method for generating an SQL operation statement according to the operation analysis data includes: The first database subsystem parses the action items and operation items of the XML operation message according to the operation parsing data; Determine the operation type according to the action item, and search for the data table item and operation parameter corresponding to the operation item; Generate an SQL operation statement according to the operation type, data table item and operation parameters.

7. The method according to claim 2, characterized in that The second database subsystem uses dlopen to call a function in a configured third-party plug-in library to process data on the XML operation message, and the method includes: The second database subsystem analyzes the XML operation message to determine the operation object and action type; 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; The function is called according to the function address to perform data processing on the XML operation message.

8. An XML-based database operating system, characterized in that: The system is used to implement an XML-based database operation method according to any one of claims 1 to 7, and the system comprises: A first XML configuration file loading module, wherein the first XML configuration file loading module is used to load a first XML configuration file, parse the first XML configuration file and create a first database subsystem, wherein the first XML configuration file is an XML configuration file that does not require processing by a third-party plug-in; An operation message loading module, the operation message loading module is used to load an XML operation message, perform operation parsing on the XML operation message, and obtain operation parsing data; An operation statement generation module is used to perform feature item matching analysis on the operation parsing data. If the matching analysis result is returned as null, an SQL operation statement is generated according to 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