Database script logic conversion system and method

Abstract

The invention discloses a database script logic conversion system and method, and relates to the technical field of database scripts. The method comprises the steps that the database scene configuration module defines configuration layer keywords, the distributed scheduling module designs script execution keywords, the weak type semantic mapping module establishes a weak type automatic conversion rule base, and the automatic testing module establishes a script performance monitoring model. The problems that the script deployment process is complex, version management is difficult, and normalization is poor are solved, cross-platform and cross-application maintenance unified management is achieved, the deployment configuration mode can be remotely maintained and managed, the mandatory requirements of historical version backtracking and metadata specification are met, and the method can be combined with other script languages to be embedded, executed and used. Complete design from demand analysis to function landing is achieved, and finally a script system integrating multi-environment adaptation, multi-language integration, usability and expansibility is formed.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of database scripts, in particular to a database script logic conversion system and method. BACKGROUND

[0002] The database script logic conversion system presents development characteristics such as automation, intelligence and high compatibility, and it increasingly focuses on automatic conversion, can automatically identify difference keywords and adjust script logic through the establishment of conversion functions and mapping relationships, and improves conversion efficiency and accuracy.

[0003] However, the existing database script logic conversion technology has the problems of complex deployment process, difficult version management, poor standardization, and the resulting low efficiency of script maintenance and management, poor usability and insufficient scalability, which are described as follows: Complex deployment process: long operation link, difficult environment adaptation, chaotic dependency processing, since the existing technology relies on manual script execution, lacks standardized deployment process and automatic strong dependency analysis capability, only does simple conversion at the syntax level, and does not consider version compatibility, resulting in poor environment compatibility and high deployment adaptation cost; Difficult version management: frequent tracking failure, conflict and high rollback risk, since the modification of the same database object by multiple teams in parallel development is prone to conflict, which may cause business logic errors, and the database script execution is irreversible, which may lose intermediate data and cause uncontrollable risk; Poor standardization: low script quality, weak readability and poor reusability, since there is a lack of unified script writing standard, resulting in chaotic script structure and excessive dependence on specific environment, which may fail during conversion; Therefore, the above problems result in low efficiency of the whole life cycle management of the database script and limited technical scalability, and thus a solution is proposed to solve the above technical defects. SUMMARY

[0004] The present application aims to solve the problems of complex script deployment process, difficult version management, poor standardization and the resulting low efficiency of script maintenance and management, poor usability and insufficient scalability.

[0005] In order to achieve the above-mentioned purpose, the present application adopts the following technical solutions: A database script logic conversion method, comprising the following steps: Step one, the database scene configuration module defines the configuration layer keywords: through the basic configuration of environment identification, command line adaptation and resource association, it is respectively used to support the environment switching and operation of local and multiple remote servers, and compatible with multi-language code embedded execution and configuration deployment; Step two, the distributed scheduling module design script execution keywords: through the environment resource switching, command execution, multi-language embedded and output control keywords, multi-scene integrated operation, and through the distributed command to realize the multi-server collaborative interaction execution; Step three, the weak type semantic mapping module establishes the weak type automatic conversion rule library: through the simple definition and conversion of variables, and marking the operator of the variable, through the quotation explicit specification for distinguishing the numerical value type comparison and string comparison of the variable, and designing the function mechanism and library reference method, so as to support logical reuse and function extension; Step four, the automatic test module establishes the script performance monitoring model: through the construction of error capture and recovery mechanism, the script exception monitoring and processing, and through the construction of date and time processing mechanism, the operation rules of multiple servers are unified, so as to obtain the sensing command execution result and output the return value.

[0006] Further, the specific operation of defining the configuration layer keywords is: Environment identification basic configuration: mark the remote server as remote, mark the encoding id of any remote server as n, then mark the remote server with encoding id n as remote_n, mark the local environment as local, and support IP and domain name configuration; Command line adaptation basic configuration: mark the remote Shell type of the remote server with encoding id n as remote_n_shell, mark the local Shell type as local_shell, and specify the command line interaction mode; Resource association basic configuration: mark the database environment as db_n, and mark the default library directory as library, so as to associate the basic configuration of external resources.

[0007] Further, the specific operation of designing script execution keywords is: Environment resource switching keywords: mark the instruction of jumping to the server environment as switch_n; mark the instruction of switching the database connection as conn_n; Command execution keywords: mark the instruction of executing sub-commands as run{}, which supports nesting; mark the instruction of distributed command as dist{}, which supports multi-server collaboration; Multi-language embedded keywords: mark the instruction of Python clause as python{}; mark the instruction of Shell clause as shell{}; mark the instruction of SQL clause as sql{}; So as to directly embed other language codes through multi-language embedded keywords; Output control keyword: the output control keyword is marked as output, the output keyword specifies the output location, including standard output, standard error and null device; wherein, the standard output is marked as stdout, the standard error is marked as stderr, and the null device is marked as null.

[0008] Further, the specific operation of establishing the weak type automatic conversion rule library is: The value of any variable is marked as var, and the variable var is directly referenced by $var, and the variable var is formatted and converted by ${var}; The operator of the variable is marked again, wherein the operator of the variable includes the assignment operator, the numerical operator and the comparison operator; The numerical type comparison and the string comparison of the variable are distinguished by explicitly specifying the quotation mark: when the string comparison between variables is performed, the quotation mark is added; otherwise, when the numerical type comparison between variables is performed, the quotation mark is not added; When the comparison between variables presents incompatible type operation, an exception result is thrown.

[0009] Further, the specific operation of designing the function mechanism and the library reference mode is: The function mechanism includes the function definition mode, the parameter reference mode and the function calling mode; The function definition mode: the function is defined as function(), and the function does not need to define the parameter type and the parameter name; The parameter reference mode: the parameter m is referenced by m; The function calling mode: the variable var is directly transmitted when the function function is called; The library reference mode: the library file is introduced through the self-defined library, and the specified function is introduced through the self-defined library function.

[0010] Further, the specific operation of establishing the script performance monitoring model is: The script exception is monitored and processed through the construction of error catching and recovery mechanism; The execution exception is captured through the exception handling function to avoid the interruption of the script; The exception handling function includes try{} and exception{}; The try{} contains the risk code segment, wherein the risk code segment includes the remote command, the database operation and the complex operation code; The exception{} defines the error processing logic, which is used to capture the exception condition of the try{} and to define the rollback logic; The type of the exception condition includes the system level exception and the logic level exception; System-level exceptions include command not found, network timeout, insufficient permissions; Logic-level exceptions include variable type mismatch and invalid date format; When the command in try {} triggers an exception, the subsequent process is terminated immediately, and the exception information is passed to exception {} for debugging and logging; When the remote server is down, the server is skipped and the other nodes are processed; when the database query result is empty, the preset default value is filled in; After the exception handling is completed, the script continues to execute the subsequent code; Then, by building a date and time processing mechanism, the operation rules of multiple servers are unified.

[0011] Further, the specific process of building a date and time processing mechanism is as follows: Date and time processing: define the date format as dateformat, and set the date operation syntax, date formatting clause, and format conversion statement to process the time variable; By reusing the system time library for format analysis, the time is converted to a millisecond-level timestamp, and addition and subtraction operations are performed to convert it back to date format, forming the operation logic; Return value acquisition: ret=run {} captures the command execution result; run {} only captures the standard output stdout, while the standard error stderr is output to the terminal; Thus, the command execution result is obtained and the return value is output; When the subsequent logic involves numerical comparison, the script automatically converts the character type variable ret to data type, and then enters exception {}; The format is unified by keyword abbreviation, where the configuration keywords are named as "function + number", i.e. remote_n and db_n, and the operator and variable reference rules are globally unified.

[0012] A database script logic conversion system, comprising a database scenario configuration module, a distributed scheduling module, a weak type semantic mapping module, and an automatic testing module, wherein the database scenario configuration module, the distributed scheduling module, the weak type semantic mapping module, and the automatic testing module are communicatively connected; the system applies the above-mentioned database script logic conversion method when executed; The database scenario configuration module is used to define configuration layer keywords; The distributed scheduling module is used to design script execution keywords; The weak type semantic mapping module is used to establish a weak type automatic conversion rule library; The automation test module is used to establish a script performance monitoring model.

[0013] In summary, due to the adoption of the technical solutions described above, the present application has the following beneficial effects: The present application improves the script maintenance and management efficiency in a distributed environment, solves the problems of complex script deployment process, difficult version management, poor standardization and other issues in the past distributed environment, realizes cross-platform and cross-application unified management, remote maintenance and management deployment configuration mode, meets the requirements of historical version backtracking and metadata specification enforcement, and can be combined with other script languages for embedded execution, realizes complete design from requirement analysis to function landing, and finally forms a script system that takes into account multi-environment adaptation, multi-language integration, ease of use and extensibility.

[0014] The present application designs script execution keywords through a distributed scheduling module, improves the efficiency and performance of script conversion in a distributed environment, reasonably allocates tasks through a load balancing strategy, avoids the problem of uneven database load, greatly shortens the time of large-scale script conversion through sharding and parallel processing, and visual execution reports and abnormal positioning functions facilitate operation and maintenance personnel to timely discover and solve problems; The present application establishes a weak type automatic conversion rule library through a weak type semantic mapping module, solves the compatibility problem of weak type of general script language and strong type of database, realizes automatic conversion and dynamic adaptation of types, enhances the security in a weak type environment through runtime assertion, prevents execution exceptions caused by type errors, and improves the reliability and stability of script conversion; The present application establishes a script performance monitoring model through an automation test module, ensures the accuracy and reliability of database script logic conversion, verifies the execution consistency of scripts in different platforms and environments, optimizes the conversion algorithm and script performance, provides a strong guarantee for stable operation of the system, and reduces the cost and error rate of manual testing. BRIEF DESCRIPTION OF DRAWINGS

[0015] Fig. 1 A step schematic diagram of the method flow of the present application is shown; Fig. 2 A connection schematic diagram of the system modules of the present application is shown. DETAILED DESCRIPTION

[0016] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0017] Embodiment 1: As Figs. 1-2 shown, a database script logic conversion system includes a database scene configuration module, a distributed scheduling module, a weak type semantic mapping module, and an automated testing module, wherein the database scene configuration module, the distributed scheduling module, the weak type semantic mapping module, and the automated testing module are in communication connection.

[0018] The working steps are as follows: S1, the database scene configuration module defines a configuration layer keyword: through the basic configuration of environment identification, command line adaptation, and resource association, local and multiple remote servers are supported for environment switching and operation, and multi-language code embedding execution and configuration deployment are compatible; S1-1, environment identification basic configuration: mark the remote server as remote, mark the coding id of any remote server as n, then mark the remote server with coding id n as remote_n, mark the local environment as local, and support IP and domain name configuration; In actual application, n identifies one or a group of server ids, which can be nested, for example, a group of servers is identified by a certain id, so that group maintenance and synchronous script execution can be realized; Synchronize the execution of key code segments and result recovery when maintaining multiple servers, the specific operation is as follows: The key code segment is used to identify the operation that must be completed synchronously by each server, and a code segment sync{} is set to identify it; The trigger method is usually initiated by the master node to send an execution signal, such as the "start executing sync{}" instruction, and all servers enter the sync{} execution phase after receiving the signal, and servers that have not received the signal must wait and are prohibited from executing in advance; The result recovery is used to determine whether all servers maintained synchronously have completed the intended operation, wherein: The recovery content includes the execution status (success / failure) of sync{} of each server, error details such as execution timeout, resource conflict, code exception, and execution time metadata; The recovery method includes active reporting: the server sends the result to the coordinator immediately after executing sync{}, such as HTTP / RPC request, writing to distributed log; S1-2, command line adaptation basic configuration: mark the remote Shell type of the remote server with coding id n as remote_n_shell, mark the local Shell type as local_shell, and specify the command line interaction method; S1-3, resource association basic configuration: mark the database environment as db_n, mark the default library directory as library, and associate the basic configuration of external resources; Among them, based on the goal of "multi-environment management, cross-language integration, and simplified operation", the core requirements are determined, the environment switching and operation of local and multiple remote servers are supported, and the embedded execution of multiple language codes such as Shell, Python, SQL is compatible, realizing configuration deployment, reducing hard coding, reducing user usage threshold, simplifying syntax, and automatic type processing; Further design the basic configuration and environment abstraction mechanism to realize unified management of multiple environments, thereby defining the configuration layer keywords.

[0019] S2, distributed scheduling module design script execution keywords: through the keywords of environment resource switching, command execution, multi-language embedding and output control, multi-scene integrated operation is carried out, and through distributed commands, multiple server collaborative interaction execution is realized; S2-1, environment resource switching keywords: mark the instruction of jumping server environment as switch_n, and abbreviate it as@n; mark the instruction of switching database connection as conn_n, and abbreviate it as&n; S2-2, command execution keywords: mark the instruction of executing sub-commands as run{}, and abbreviate it as!, which is used to support nesting; mark the instruction of distributed commands as dist{}, and abbreviate it as~, which is used to support multi-server collaboration; S2-3, multi-language embedding keywords: mark the instruction of Python clause as python{}, and abbreviate it as!:; mark the instruction of Shell clause as shell{}, and abbreviate it as!!; mark the instruction of SQL clause as sql{}, and abbreviate it as!%; so as to directly embed other language codes; S2-4, output control keywords: mark the output control as output, the output keyword specifies the output location, including standard output, standard error and null device; Among them, mark the standard output as stdout, mark the standard error as stderr, and mark the null device as null; Among them, the standard output stdout refers to the default output channel of the program running, such as terminal, console, used for outputting normal execution results or information; the standard error stderr is used for outputting error information generated in the program running process, such as exception, error prompt, so as to distinguish normal output (standard output stdout) and error information; the null device null indicates that the contents output to this place will be discarded, not displayed or saved, and is often used to shield unnecessary output, such as temporary debugging information and redundant logs; the design of the output position makes the script can flexibly control the output direction of the content, meet the information display or processing needs in different scenes, such as outputting normal results to the console, recording error information to a specific channel, or ignoring irrelevant output.

[0020] S3, the weak type semantic mapping module establishes a weak type automatic conversion rule library: through the weak type automatic conversion rule library, without explicitly specifying the variable type, the automatic conversion in a specific context is realized, through the simple definition and conversion of variables, and the operator of the variable is marked, the quotation is used to explicitly specify to distinguish the numerical comparison and string comparison of the variable, and the exception is output for the operation of incompatible types, and the function mechanism and library reference mode are designed, so as to support logic reuse and function extension; S3-1, the specific operation of establishing a weak type automatic conversion rule library is: S3-101, the value of any variable is marked as var, and the variable var is directly referenced through $var, and the variable var is formatted and converted through ${var}; S3-102, the operator of the variable is marked again, wherein the operator of the variable includes assignment operator, numerical operator and comparison operator; The assignment operator includes = (assignment); The numerical operator includes + (add), - (subtract), * (multiply), / (floating point division), / / (integer division); The comparison operator includes == (equal), > (greater than), < (less than): S3-103, the quotation is used to explicitly specify to distinguish the numerical comparison and string comparison of the variable: when the string comparison between variables is performed, the quotation is added; otherwise, when the numerical comparison between variables is performed, the quotation is not added; When the variables are compared, the operation of incompatible types is presented, and an exception result is thrown; S3-2, the specific operation of designing function mechanism and library reference mode is: The function mechanism includes function definition mode, parameter reference mode and function calling mode; The function definition mode: the function is defined as function(), and the function does not need to define the parameter type and parameter name; Parameter reference mode: reference parameter m through $m; Function call mode: directly pass in variable var when calling function function; Library reference mode: Import library file through import_mylib custom library; Import specified function through import_function_from_mylib custom library function; Thus, code modularization is achieved.

[0021] S4, the script performance monitoring model is established by the automated test module: through the construction of error capture and recovery mechanism, the script exception is monitored and processed, so that the script can still be controlled to execute when the script is abnormal, rather than directly crashing, and through the construction of date and time processing mechanism, the operation rules of multiple servers are unified, so that the perception command execution result is obtained and the return value is output; S4-1, the script exception is monitored and processed through the construction of error capture and recovery mechanism; The execution exception is captured through the exception handling function to avoid script interruption; The exception handling function includes try{} and exception{}; try{} contains a risk code segment, wherein the risk code segment includes remote commands, database operations and complex operation codes, which may cause abnormal conditions due to external dependencies or logical errors; exception{} defines error handling logic for capturing the abnormal conditions of try{}, and customizes rollback logic, such as deleting temporary files and restoring configurations; The types of abnormal conditions include system-level exceptions and logic-level exceptions; System-level exceptions include non-existent commands, network timeouts, insufficient permissions, and are triggered by the exit code of the run{} and switch_n commands of the script execution keywords; The logic-level exceptions include variable type mismatch and invalid date format; the logic-level exceptions are triggered by the output results of the weak type automatic conversion rule library; When the command of try{} triggers an exception, the subsequent process is terminated immediately, and the exception information is transferred to exception{}, the exception is debugged and the log is recorded; When the remote server is down, the server is skipped and other nodes are processed; when the database query result is empty, the preset default value is filled to avoid subsequent logic errors; After the exception handling is completed, the script continues to execute the subsequent code; So that the script can still be controlled to execute when the script is abnormal, rather than directly crashing; S4-2, by building a date and time processing mechanism, unify multiple server operation rules; Date and time processing: define the date format tag as dateformat, and set the date operation syntax, date formatting clause, and format conversion statement to process time variables; Format analysis by reusing system time library, such as Linux date command logic, format symbols include %Y (year), %m (month), %d (day), %H (hour); Convert time to millisecond timestamp and perform addition and subtraction operations to convert back to date format, form operation logic, and avoid manual calculation of time zone, leap year, and other complex problems; Return value acquisition: ret=run{} captures the command execution result, which is convenient for logical judgment; run{} only captures standard output stdout, while standard error stderr is output to the terminal; Thus, the command execution result is obtained and the return value is output; When the subsequent logic involves numerical comparison, the script automatically converts the character type variable ret to data type, and then enters exception{}; S4-3, further unify the format by keyword abbreviation to reduce the use cost, the keyword abbreviation is as follows: Environment resource switching keyword: the instruction for jumping to the server environment is marked as switch_n, and abbreviated as@n; the instruction for switching the database connection is marked as conn_n, and abbreviated as&n; Command execution keyword: the instruction for executing sub-commands is marked as run{}, and abbreviated as!; the instruction for distributed commands is marked as dist{}, and abbreviated as~; Multi-language embedded keyword: the instruction for Python clause is marked as python{}, and abbreviated as!:; the instruction for Shell clause is marked as shell{}, and abbreviated as!!; the instruction for SQL clause is marked as sql{}, and abbreviated as!%; Among them, the configuration keywords adopt the naming method of "function+number", that is, remote_n and db_n, and the operator and variable reference rules are globally unified to ensure the minimum learning cost of users.

[0022] In summary, the present application improves the script maintenance and management efficiency in a distributed environment, solves the problems of complex script deployment process, difficult version management, poor standardization and other problems in the previous distributed environment, realizes cross-platform and cross-application unified management, remote maintenance management deployment configuration mode, meets the requirements of historical version backtracking and metadata specification, and can be combined with other script languages for embedded execution, realizes complete design from requirement analysis to function landing, and finally forms a script system considering multi-environment adaptation, multi-language integration, ease of use and expansibility.

[0023] The present application designs script execution keywords through a distributed scheduling module, improves the efficiency and performance of script conversion in a distributed environment, reasonably allocuses tasks through a load balancing strategy, avoids the problem of uneven database load, greatly shortens the time of large-scale script conversion through sharding and parallel processing, and visual execution report and abnormal positioning function facilitate operation and maintenance personnel to timely find and solve problems. The present application establishes a weak type automatic conversion rule library through a weak type semantic mapping module, solves the compatibility problem of weak type of general script language and strong type of database, realizes automatic conversion and dynamic adaptation of types, enhances the security in a weak type environment through runtime assertion, prevents execution exception caused by type error, and improves the reliability and stability of script conversion. The present application establishes a script performance monitoring model through an automatic test module, ensures the accuracy and reliability of database script logic conversion, verifies the execution consistency of scripts in different platforms and environments, optimizes conversion algorithm and script performance, provides a strong guarantee for stable operation of the system, and reduces the cost and error rate of manual testing.

[0024] The above embodiments can be realized by software, hardware, firmware or any combination thereof, in whole or in part. When realized by software, the above embodiments can be realized in the form of a computer program product in whole or in part. Those skilled in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized by hardware or software depends on the specific application and design constraints of the technical solutions.

[0025] The units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, i.e. they can be located in one place or distributed on multiple network units. Part or all of the units can be selected to realize the purpose of the present embodiment scheme according to actual needs.

[0026] The above merely describes preferred specific embodiments of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art, according to the technical solution and inventive concept of the present application, makes equivalent replacement or change within the technical range disclosed by the present application, which should be covered within the protection scope of the present application.

Claims

1. A database script logic conversion method, characterized by: The following steps are involved: Step 1: The database scenario configuration module defines configuration layer keywords. This module uses basic configurations for environment identification, command line adaptation, and resource association to support environment switching and operations between local and multiple remote servers, as well as compatibility with embedded execution of multi-language code and configuration-based deployment. Step 2: Design script execution keywords for the distributed scheduling module: This module integrates multiple scenarios through keywords for environment resource switching, command execution, multi-language embedding, and output control, and enables multi-server collaborative interactive execution through distributed commands. Step 3: The weak type semantic mapping module establishes a weak type automatic conversion rule library. This module uses concise variable definitions and conversions, labels variable operators, explicitly specifies numeric comparisons and string comparisons using quotation marks, and designs function mechanisms and library reference methods to support logic reuse and functional expansion. Step 4: The automated testing module establishes a script performance monitoring model: by building an error capture and recovery mechanism, it monitors and handles script exceptions, and by building a date and time processing mechanism, it unifies the operation rules of multiple servers to obtain the perceived command execution results and output the return value.

2. A database script logic conversion method according to claim 1, characterized in that: The specific operations for defining configuration layer keywords are: Basic configuration of environment identification: mark the remote server as remote, mark the coding ID of any remote server as n, then mark the remote server with coding ID n as remote_n, mark the local environment as local, and support IP and domain name configuration; Basic configuration for command line adaptation: mark the remote shell type of the remote server with code ID n as remote_n_shell, mark the local shell type as local_shell, and specify the command line interaction mode; Resource association basic configuration: Mark the database environment as db_n and the default library directory as library to associate the basic configuration of external resources.

3. A database script logic conversion method according to claim 2, characterized in that: The specific operations of designing script execution keywords are: Environment resource switching keywords: mark the instruction for jumping to the server environment as switch_n; mark the instruction for switching the database connection as conn_n; Command execution keywords: Mark the instructions for executing subcommands as run{} to support nesting; mark the instructions for distributed commands as dist{} to support multi-server collaboration; Multi-language embedded keywords: Mark the Python clause instructions as python{}; mark the Shell clause instructions as shell{}; mark the SQL clause instructions as sql{}; Thus, other language codes can be directly embedded through multilingual embedded keywords; Output control keywords: mark the output control as output. The output keyword specifies the output location, including standard output, standard error, and null device. Among them, mark the standard output as stdout, the standard error as stderr, and the null device as null.

4. A database script logic conversion method according to claim 3, characterized in that: The specific operations for establishing a weak type automatic conversion rule base are: Mark the value of any variable as var, use $var to directly reference the variable var, and use ${var} to format the variable var; Then mark the variable operators, where the variable operators include assignment operators, numerical operators, and comparison operators; Use quotation marks to explicitly specify the difference between numeric comparison and string comparison of variables: when strings are compared between variables, quotation marks are added; otherwise, when numeric comparison is performed between variables, quotation marks are not added; When incompatible types are compared between variables, an exception is thrown.

5. A database script logic conversion method according to claim 4, characterized in that: The specific operations of designing the function mechanism and library reference method are as follows: Function mechanism includes function definition method, parameter reference method and function call method; Function definition method: define the function as function(){}, the function does not need to define parameter types and parameter names; Parameter reference method: reference parameter m through $m; Function calling method: directly pass in the variable var when calling the function function; Library reference method: Import library files through custom libraries, and import specified functions through custom library functions.

6. A database script logic conversion method according to claim 5, characterized in that: The specific operations for establishing a script performance monitoring model are: Monitor and handle script exceptions by building an error capture and recovery mechanism; Capture execution exceptions through exception handling functions to avoid script interruption; Exception handling functions include try{} and exception{}; try{} contains risky code segments, including remote commands, database operations, and complex calculation codes; exception{} defines error handling logic, which is used to capture exceptions in try{} and customize rollback logic; The types of abnormal situations include system-level abnormalities and logic-level abnormalities; System-level exceptions include command non-existence, network timeout, and insufficient permissions; Logical-level exceptions include variable type mismatches and invalid date formats; When the try{} command triggers an exception, the subsequent process is terminated immediately, and the command jumps to exception{} to pass the exception information, debug the exception, and record the log. When a remote server goes down, it will be skipped and processing will continue on other nodes. When the database query result is empty, the default value will be filled. When the exception handling is completed, the script continues to execute subsequent code; Then, by building a date and time processing mechanism, the operation rules of multiple servers can be unified.

7. A database script logic conversion method according to claim 6, characterized in that: The specific process of building a date and time processing mechanism is as follows: Date and time processing: mark the date format definition as dateformat, and set the date operation syntax, date formatting clause and format conversion statement to process the time variable; By reusing the system time library to perform format parsing, the time is converted into a millisecond timestamp, and then addition and subtraction operations are performed to convert it back to date format to form the operation logic; Return value acquisition: ret=run{} captures the command execution result; run{} only captures the standard output stdout, while the standard error stderr is output to the terminal; Thus, the execution result of the perception command is obtained and the return value is output; When the subsequent logic involves numerical comparison, the script automatically converts the character type variable ret to a data type and then enters exception{}; The format is unified through keyword abbreviations. Configuration keywords are all named using "function + number", i.e. remote_n and db_n, and the operator and variable reference rules are globally unified.

8. A database script logic conversion system, characterized by: The system comprises a database scenario configuration module, a distributed scheduling module, a weakly typed semantic mapping module, and an automated testing module, wherein the database scenario configuration module, the distributed scheduling module, the weakly typed semantic mapping module, and the automated testing module are communicatively connected to each other; when the system is applied, a database script logic conversion method according to any one of claims 1 to 7 is executed; The database scenario configuration module is used to define configuration layer keywords; The distributed scheduling module is used to design script execution keywords; The weak type semantic mapping module is used to establish a weak type automatic conversion rule base; The automated testing module is used to establish a script performance monitoring model.

Images