Method, device and medium for semantic drift verification for heterogeneous database migration

Abstract

The application discloses a semantic drift verification method and device for heterogeneous database migration and a medium, and relates to the technical field of databases. The method comprises the following steps: executing an implicit conversion capability probe statement on a source database and a target database respectively, generating a source database implicit conversion capability matrix and a target database implicit conversion capability matrix based on the probe execution results, and calculating the difference set of the two; analyzing the structured query language statement and the database object definition in the database, extracting the binding type and the binding interface corresponding to the parameter placeholder in the expression unit and the structured query language statement, and identifying the implicit type conversion risk expression; generating a trigger sample set based on the implicit type conversion risk expression, executing a verification statement in the source database and the target database respectively, and obtaining the execution results; based on the execution results, determining whether there is an implicit type conversion drift, obtaining the behavior fingerprint difference of the two, determining the drift reason, and generating a repair suggestion.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a semantic drift verification method, device and medium for heterogeneous database migration. Background Technology

[0002] With the advancement of domestic database substitution and heterogeneous database migration, migration verification technology has made some progress. Existing tools can achieve field-level type mapping, automatic SQL syntax conversion, static rule base compatibility scanning, and data consistency verification. However, the following problems still exist in existing heterogeneous database migration: Existing solutions rely on static rule bases to assess compatibility risks. However, implicit conversion rules in databases are affected by dynamic factors such as version, compatibility mode, character set, and sorting rules. Static rules are neither accurate nor complete. Furthermore, existing solutions only analyze SQL text and cannot perceive the specific types of application-layer parameter bindings. In the same SQL statement, whether parameters are bound through a string interface or an integer interface may trigger completely different conversion paths, and this dimension of risk is completely ignored. Secondly, error codes, type names, and result formats differ between different databases, making it impossible to directly compare the original execution results.

[0003] Therefore, how to identify database instance conversion capabilities through implicit probes, and how to accurately compare cross-database execution behaviors by identifying implicit type conversion risks at the expression level and by comparing behavior fingerprint normalization, thereby enabling drift classification, drift attribution, repair suggestion generation, and post-repair regression verification, has become an urgent technical problem to be solved. Summary of the Invention

[0004] This application provides a semantic drift verification method, device, and medium for heterogeneous database migration, which solves the following technical problem: how to identify the database instance conversion capability through implicit probes, and how to identify implicit type conversion risks at the expression level and achieve accurate comparison of cross-database execution behavior through behavior fingerprint normalization comparison, thereby realizing drift classification, drift attribution, repair suggestion generation, and post-repair regression verification.

[0005] In a first aspect, embodiments of this application provide a semantic drift verification method for heterogeneous database migration. The method includes: executing implicit transformation capability probe statements on both the source and target databases to obtain probe execution results; generating implicit transformation capability matrices for the source and target databases based on the probe execution results; calculating the difference set between the implicit transformation capability matrices of the source and target databases; parsing structured query language statements and database object definitions in the source and target databases to extract the binding types and binding interfaces corresponding to expression units and parameter placeholders in the structured query language statements; and based on the expression units... The system identifies implicit type conversion risk expressions by analyzing the mapping paths between the source and target types of the metadata, binding types, binding interfaces, difference sets, and operands. Based on these risk expressions, a trigger sample set is generated to produce verification statements. These statements are then executed in both the source and target databases to obtain execution results. Based on these results, the system determines whether implicit type conversion drift exists, obtaining behavioral fingerprint differences between the source and target databases. Finally, based on the implicit type conversion risk expressions, trigger sample set, and behavioral fingerprint differences, the system identifies the cause of the drift and generates remediation suggestions.

[0006] In one implementation of this application, implicit conversion capability probe statements are executed on the source database and the target database respectively to obtain probe execution results. Specifically, this includes: selecting implicit conversion capability probe statements corresponding to the source database and the target database from a preset probe template library and executing them to obtain probe execution results; wherein, the probe statements include comparison probes, assignment probes, function input parameter probes, arithmetic operation probes, date parsing probes, verification probes, time interval parsing probes, null probes, and sorting rule probes; the probe execution results include execution status, return type, exception category, and error stage.

[0007] In one implementation of this application, an implicit transformation capability matrix of the source database and an implicit transformation capability matrix of the target database are generated based on the probe execution results. The difference set between the source database implicit transformation capability matrix and the target database implicit transformation capability matrix is ​​calculated. Specifically, this includes: summarizing the implicit transformation capability records corresponding to all probe statements in the source database into a source database implicit transformation capability matrix, and summarizing the implicit transformation capability records corresponding to all probe statements in the target database into a target database implicit transformation capability matrix; traversing the records with the same probe identifier and the same probe context in the source database implicit transformation capability matrix and the target database implicit transformation capability matrix, and comparing the differences in execution status, return type, exception category, and error stage item by item to generate a difference set.

[0008] In one implementation of this application, the structured query language statements and database object definitions in the source and target databases are parsed to extract expression units and the binding types and binding interfaces corresponding to parameter placeholders in the structured query language statements. Specifically, this includes: performing lexical and syntactic analysis on the structured query language statements and database object definitions to generate an expression tree; traversing the expression tree to extract syntactic structures containing fields, constants, parameter placeholders or function calls, and operators or function names as expression units, and recording the expression context to which the expression unit belongs; extracting the parameter numbers of each parameter placeholder in the structured query language statements, and determining the binding type and binding interface corresponding to each parameter number based on the binding configuration or driver logs collected by the application, and associating the binding type and binding interface with the corresponding parameter placeholder.

[0009] In one implementation of this application, implicit type conversion risk expressions are identified based on expression units, binding types, binding interfaces, difference sets, and the mapping paths between the source and target types of each operand. Specifically, this includes: determining the target type of the operands in the expression unit after migration to the target database based on the source types of the operands in the source database and preset type mapping rules, and recording the changes in numerical range, precision scale, format parsing rules, null value handling rules, validation strictness, and sorting rules from the source type to the target type to construct a mapping path; and searching for difference records in the difference set that match the combination of operator and operand source types or function parameter types of the expression unit, based on the operator or function names contained in the expression unit, the expression context to which the expression unit belongs, and the mapping paths of each operand, to obtain implicit type conversion risk expressions.

[0010] In one implementation of this application, a set of trigger samples is generated based on an implicit type conversion risk expression to generate a verification statement. The verification statement is then executed in both the source and target databases to obtain execution results for the source and target databases, respectively. Specifically, this includes: constructing a set of ternary coverage units composed of a mapping path, expression context, and behavior difference dimension to generate the set of trigger samples; and generating source and target database verification statements based on each trigger sample and its corresponding risk expression in the set of trigger samples, and executing the verification statements respectively to obtain execution results for the source and target databases that include execution status, number of returned rows, information on returned columns, return type, return result, exception information, number of affected rows, and side effect information.

[0011] In one implementation of this application, based on the execution results of the source database and the target database, it is determined whether implicit type conversion drift exists, in order to obtain behavioral fingerprint differences between the source database and the target database. Specifically, this includes: normalizing the execution results of the source database and the target database to generate behavioral fingerprints for the source database and the target database; comparing the difference types of the behavioral fingerprints of the source database and the target database item by item, and performing a weighted summation based on the weight coefficients corresponding to the difference types to obtain the drift difference value; wherein, the difference types include execution status difference, return row number difference, return type difference, result summary difference, sorting summary difference, anomaly category difference, error stage difference, affected row number difference, and side effect difference; if the drift difference value is greater than a preset difference threshold, it is determined that the risk expression has hard drift; if the drift difference value is greater than 0 and less than the preset difference threshold, it is determined that the risk expression has tolerable drift; if the drift difference value is 0, it is determined that the risk expression has no drift, and the determination result is used as the behavioral fingerprint difference.

[0012] In one implementation of this application, the drift cause is determined based on implicit type conversion risk expressions, trigger sample sets, and behavioral fingerprint differences to generate remediation suggestions. Specifically, this includes: when a risk expression is determined to have hard drift or tolerate drift, extracting execution state difference type, exception category difference, return type difference, and result summary difference from behavioral fingerprint differences; matching the risk pattern, expression context, change attributes in the mapping path, binding type and binding interface of the risk expression, as well as the execution state difference type, exception category difference, return type difference, and result summary difference, with preset attribution rules to determine the drift cause; wherein, the drift cause includes implicit conversion differences between strings and numbers, date and time format parsing differences, numerical range shrinkage differences, validation rule differences, time interval format parsing differences, null value and empty string processing differences, function input parameter type matching differences, sorting rule differences, and implicit conversion differences caused by parameter binding types; generating corresponding remediation suggestions based on the drift cause, and associating the remediation suggestions with the risk expression, trigger sample set, and mapping path for output.

[0013] Secondly, embodiments of this application also provide a semantic drift verification device for heterogeneous database migration. The device includes: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores instructions executable by the at least one processor, which, when executed, enable the at least one processor to: execute implicit transformation capability probe statements on both the source and target databases to obtain probe execution results, and generate implicit transformation capability matrices for the source and target databases based on the probe execution results, thereby calculating the difference set between the implicit transformation capability matrices of the source and target databases; and parse structured query language statements and database object definitions in the source and target databases to extract expressions. The system identifies implicit type conversion risk expressions by determining the binding types and binding interfaces corresponding to parameter placeholders in expression units and structured query language statements, and by analyzing the mapping paths between the source and target types of each operand based on the expression units, binding types, binding interfaces, difference sets, and the implicit type conversion risk expressions. It then generates a trigger sample set based on these implicit type conversion risk expressions to generate verification statements, which are executed in both the source and target databases to obtain execution results. Based on these results, it determines whether implicit type conversion drift exists, obtaining behavioral fingerprint differences between the source and target databases. Finally, it identifies the cause of the drift based on the implicit type conversion risk expressions, the trigger sample set, and the behavioral fingerprint differences, generating remediation suggestions.

[0014] Thirdly, embodiments of this application also provide a non-volatile computer storage medium for semantic drift verification of heterogeneous database migration, storing computer-executable instructions. These computer-executable instructions are configured to: execute implicit transformation capability probe statements on both the source and target databases to obtain probe execution results; generate implicit transformation capability matrices for the source and target databases based on the probe execution results; calculate the difference set between the implicit transformation capability matrices of the source and target databases; and parse structured query language statements and database object definitions in the source and target databases to extract expression units and bindings corresponding to parameter placeholders in the structured query language statements. The system identifies implicit type conversion risk expressions based on the type and binding interface, and on the mapping path between the source and target types of each operand, including the expression unit, binding type, binding interface, difference set, and each operand's source and target types. It then generates a trigger sample set based on these implicit type conversion risk expressions to produce verification statements, which are executed in both the source and target databases to obtain execution results. Based on these results, it determines whether implicit type conversion drift exists, obtaining behavioral fingerprint differences between the source and target databases. Finally, it identifies the cause of the drift based on the implicit type conversion risk expressions, the trigger sample set, and the behavioral fingerprint differences, generating remediation suggestions.

[0015] This application provides a semantic drift verification method, device, and medium for heterogeneous database migration, which has the following advantages: By executing implicit conversion capability probes on the source and target databases respectively, the actual implicit conversion behavior of the two database instances can be dynamically obtained, and the probe execution results can be summarized into a capability matrix and the difference set between the two can be calculated, thereby overcoming the defect that traditional static rule bases cannot reflect the actual behavior of specific database instances; by extracting the binding type and binding interface corresponding to the expression unit and parameter placeholder, and then combining the mapping path between the source type and target type of the difference set and operands, implicit type conversion risk expressions can be identified, and the risk positioning can be refined from the traditional field level or statement level to the expression level; by executing verification statements on the source and target databases respectively, collecting the execution results and generating a behavior fingerprint with a unified structure, the interference of the original differences between different databases on the comparison results is eliminated, making the comparison of cross-database execution behavior more accurate and reliable. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1A flowchart of a semantic drift verification method for heterogeneous database migration provided in this application embodiment; Figure 2 This is a schematic diagram of the internal structure of a semantic drift verification device for heterogeneous database migration, provided as an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] This application provides a semantic drift verification method, device, and medium for heterogeneous database migration, which solves the following technical problem: how to identify the database instance conversion capability through implicit probes, and how to identify implicit type conversion risks at the expression level and achieve accurate comparison of cross-database execution behavior through behavior fingerprint normalization comparison, thereby realizing drift classification, drift attribution, repair suggestion generation, and post-repair regression verification.

[0019] The technical solutions proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0020] Figure 1 This document provides a flowchart of a semantic drift verification method for heterogeneous database migration, as illustrated in an embodiment of this application. Figure 1 As shown in the figure, the semantic drift verification method for heterogeneous database migration provided in this application embodiment specifically includes the following steps: Step 10: Execute implicit transformation capability probe statements on the source database and the target database respectively to obtain probe execution results, and generate implicit transformation capability matrices for the source database and the target database based on the probe execution results, so as to calculate the difference set between the implicit transformation capability matrices of the source database and the target database.

[0021] As an optional embodiment, implicit transformation capability probe statements are executed on the source database and the target database respectively to obtain probe execution results. Based on the probe execution results, implicit transformation capability matrices of the source database and the target database are generated to calculate the difference set between the implicit transformation capability matrices of the source database and the target database. Specifically, it may include: Step 101: Selecting implicit transformation capability probe statements corresponding to the source database and the target database from a preset probe template library and executing them to obtain probe execution results.

[0022] In this step, a standardized probe template library is first pre-built. This library categorizes probe statements according to different database products, versions, compatibility modes, data type interaction scenarios, and expression contexts. Each probe template corresponds to different implicit type conversion behavior verification scenarios, covering all core conversion behavior verification scenarios such as cross-type comparison, assignment operations, function parameter matching, date / text parsing, structured data verification, time interval parsing, null value / empty string differentiation, and character sorting matching. Each probe template encapsulates standardized query, assignment, and function call statement structures adapted to the corresponding verification target. Secondly, the basic environment identification information of the source and target databases corresponding to the current migration task is read, including key environment attributes such as database type, release version, enabled compatibility modes, character set, collation rules, and parameter configurations. Based on this set of environment identification information, [the system then proceeds from...]. A precise selection process is performed using a pre-defined probe template library to identify a subset of probe statements that are fully compatible with the source database's operating environment and a subset of probe statements that are compatible with the target database's operating environment. After selection, independent probe execution sessions are established for the source and target database instances, respectively. Following the execution order built into the template library, the selected probe statement subsets are sequentially sent to the corresponding database instances for execution in batches. After all probe statements have been executed, the complete set of probe execution results generated by the source and target databases is structurally encapsulated to form a set of implicit conversion capability raw records specific to each database instance. This set fully carries the implicit type conversion behavior characteristics of the current database instance under its own version, mode, character set, and parameter configuration, serving as the underlying basis for subsequent calculations of the implicit conversion capability differences between the source and target databases and for identifying expression-level drift risks.

[0023] Step 102: Summarize the implicit transformation capability records corresponding to all probe statements in the source database into a source database implicit transformation capability matrix, and summarize the implicit transformation capability records corresponding to all probe statements in the target database into a target database implicit transformation capability matrix.

[0024] In this step, the implicit transformation capability records collected after executing all probe statements in the source database are first standardized and organized. Each independent probe record carries structured attribute fields such as database environment identifier, probe scenario identifier, input type involved in the transformation, transformation target type, expression context to which the probe belongs, operation or function identifier, and complete probe execution result. After completing the execution of all source database probe statements and the collection of individual records, all scattered individual capability records are collected and integrated according to a unified data organization standard. Using database instance environment attributes, transformation participation type, operation context, and behavior feedback as hierarchical organization dimensions, all records are orderly classified, deduplicated, and structured filled to form a complete and well-organized source database implicit transformation capability matrix. This matrix fully carries the current source database instance's implicit transformation capability within itself. Under different versions, compatibility modes, character sets, sorting rules, and parameter configurations, the matrix contains native implicit conversion behavior features corresponding to various types of interaction scenarios. Each data entry in the matrix corresponds to a specific type conversion verification scenario, fully covering all implicit conversion verification dimensions included in the probe template library. The same applies to the target database matrix. After the two sets of matrices are constructed, the implicit conversion capability matrix of the source database and the implicit conversion capability matrix of the target database form a standardized dataset that is dimensionally aligned and cross-comparable. The matrix fully captures all implicit conversion behavior features generated by the database instances on both sides based on the real operating environment. This provides a standardized and unified data carrier for subsequent comparison of the two sets of matrices through the difference calculation function and extraction of the implicit conversion capability difference set of the two databases. This supports the subsequent identification of expression-level implicit conversion drift risks and the construction of targeted trigger samples.

[0025] Step 103: Traverse the implicit transformation capability matrix of the source database and the implicit transformation capability matrix of the target database for records with the same probe identifier and the same probe context, and compare the differences in execution status, return type, exception category and error stage item by item to generate a difference set.

[0026] In this step, the probe identifier and the context of the expression to which the probe belongs are used as the matching primary keys. Each complete implicit transformation capability record in the implicit transformation capability matrix of the source database is read sequentially. The probe identifier and probe context, two sets of core matching fields, are extracted for the current record. Then, all records in the implicit transformation capability matrix of the target database are traversed to retrieve corresponding records with completely identical probe identifiers and completely matching probe contexts. This establishes a one-to-one correspondence between the source and target databases for the same verification scenario. After matching, the overall execution status of the probe statement is compared to distinguish the fundamental differences in the execution results between the two databases. Next, the return types output after the transformation operation are compared to identify whether the data types derived by the two databases under the same transformation scenario are different. Finally, the anomaly category identifier is compared. If the probe execution process triggers an error, the uniformly mapped anomaly classification information is used as the comparison basis to distinguish the differences in the classification of similar transformation anomalies between the two databases. Finally, the error stage identifiers are compared to pinpoint the execution stage where the error occurred, such as statement parsing, type inference, data computation, or result output, to determine if there are differences in the triggering sequence of similar anomalies. If any of the above comparison dimensions show inconsistencies in the recorded information on both sides, the complete scene information and the differences in each dimension corresponding to the matched records are encapsulated into an independent difference entry and included in the global conversion capability difference set. If all information in the four comparison dimensions is completely consistent, it is determined that there are no implicit conversion behavior differences in the probe scene, and no corresponding difference entry is generated. After the entire matrix traversal, matching, and item-by-item comparison process is completed, all captured difference entries are uniformly collected and integrated to form a complete implicit conversion capability difference set between the source library and the target library. Each entry in the set is associated with the corresponding probe identifier, probe context, and detailed difference content in each dimension, providing a standardized difference basis for subsequent expression-level implicit conversion drift risk identification and targeted trigger sample generation.

[0027] Step 20: Parse the Structured Query Language statements and database object definitions in the source and target databases to extract the binding types and binding interfaces corresponding to the expression units and parameter placeholders in the structured query language statements. Based on the expression units, binding types, binding interfaces, difference sets, and the mapping paths between the source and target types of each operand, identify implicit type conversion risk expressions.

[0028] As an optional implementation, the structured query language statements and database object definitions in the source and target databases are parsed to extract the binding types and binding interfaces corresponding to the expression units and parameter placeholders in the structured query language statements. Based on the expression units, binding types, binding interfaces, difference sets, and the mapping paths between the source and target types of each operand, implicit type conversion risk expressions are identified. Specifically, this may include: Step 201: performing lexical and syntactic analysis on the structured query language statements and database object definitions to generate an expression tree.

[0029] In this step, the structured query language statement to be verified and the definition text of various database objects are read. Lexical analysis is performed first to split the text into independent lexical units, distinguishing different types of units such as fields, constants, parameter placeholders, operators, function identifiers, and constraint keywords. Irrelevant whitespace and comments are filtered out. Based on the split lexical units, syntax analysis is performed to match the corresponding database syntax rules and verify the legality of the syntax structure of the statement and object definitions. Logical units such as operations, assignments, conditions, function calls, and constraint judgments are decomposed layer by layer. According to the operation priority, expression hierarchy, and object hierarchy association rules, the decomposed logical units are organized and spliced ​​layer by layer to generate a hierarchical expression tree. Each node in the tree corresponds to an independent expression unit, distinguishing the left operand, operator, right operand, and context. It fully carries the combination and association relationships of fields, constants, parameters, functions, and operators, providing a structured carrier for subsequent extraction of expression units and inference of data types.

[0030] Step 202: Traverse the expression tree to extract syntactic structures containing fields, constants, parameter placeholders or function calls, and operators or function names as expression units, and record the expression context to which the expression unit belongs.

[0031] In this step, the complete expression tree hierarchy is traversed layer by layer, identifying various basic syntax nodes within the tree. Syntax structures containing any one of the following elements—fields, constants, parameter placeholders, or function calls—and carrying operator or function identifiers are selected. These structures are encapsulated as independent expression units. During the traversal, the logical scenario to which the expression unit belongs is simultaneously located, distinguishing between different scenarios such as conditional judgments, data assignments, function parameters, sorting constraints, validation rules, and trigger branches. The scenario attributes are recorded as expression context and bound to the corresponding expression unit for storage. After all nodes have been traversed, all selected expression units are aggregated, each with its own unique context identifier. The complete information on the operational elements, computational logic, and usage scenarios within the expression is preserved, providing structured foundational material for subsequent type inference and implicit conversion risk identification.

[0032] Step 203: Extract the parameter numbers of each parameter placeholder in the Structured Query Language statement, and based on the binding configuration or driver logs collected by the application, determine the binding type and binding interface corresponding to each parameter number, and associate the binding type and binding interface with the corresponding parameter placeholder.

[0033] In this step, the expression units generated by the structured query language parsing are first traversed to locate all parameter placeholders within the statement. Unique parameter numbers are assigned sequentially based on the order in which the placeholders appear in the text, completing the ordered numbering and location marking of all placeholders. Then, two types of data sources are read: the application-side driver runtime logs and parameter binding configuration files. Binding records corresponding to each structured query language statement are extracted from these sources. These records contain key information such as the matching SQL fingerprint, parameter number, binding data type, and the driver interface identifier that performed the binding operation. Using the SQL fingerprint and parameter number as the matching association primary keys, the binding type and binding interface information read from the logs and configuration are bound one-to-one to the parameter placeholder nodes with the same number in the expression tree, establishing a strong association mapping relationship between parameter placeholders, parameter numbers, binding types, and binding interfaces. After association, each parameter placeholder node is accompanied by complete parameter binding context information, which can distinguish the type binding differences brought by different driver interfaces. This incorporates application-layer parameter binding behavior into the expression risk identification system, providing complete data support for subsequent construction of parameter binding class trigger samples and identification of implicit conversion drift caused by binding types.

[0034] Step 204: Based on the source type of the operands in the expression unit in the source database and the preset type mapping rules, determine the target type of the operands in the expression unit after they are migrated to the target database, and record the changes in numerical range, precision scale, format parsing rules, null value handling rules, validation strictness and sorting rules between the source type and the target type, so as to construct the mapping path.

[0035] In this step, the native data types of the operands in the source database system are inferred by using the metadata, constant definitions, and parameter binding information corresponding to each operand within the expression unit, serving as the source type benchmark for mapping derivation. A preset cross-database type mapping rule set is retrieved, and combined with the type specifications of the target database, the corresponding target type for each operand after migration is obtained to adapt to the target database environment. After completing the type matching at both ends, various semantic difference attributes generated during the transition from the source type to the target type are systematically reviewed, covering six dimensions of change characteristics: numerical value range constraints, numerical precision and decimal scale definitions, parsing logic for text and time-related data, the mechanism for distinguishing between empty strings and null values, stringent standards for data validity verification, and character comparison and sorting rules. Each attribute item with differences is fully recorded. The source type, target type, and all the reviewed semantic change attributes are integrated and encapsulated to form a complete type mapping path. Each mapping path is bound to its corresponding expression unit, clearly recording potential semantic change points throughout the type migration process. This provides a complete basis for type conversion features to identify drift risks and generate targeted trigger samples by combining the implicit conversion capability difference matrix.

[0036] Step 205: Based on the operator or function name contained in the expression unit, the expression context to which the expression unit belongs, and the mapping path of each operand, search the difference set for difference records that match the combination of operator, operand source type, or function input parameter type of the expression unit to obtain the implicit type conversion risk expression.

[0037] In this step, the extracted expression unit is used as the analysis carrier. First, the operator or function identifiers within the unit and the context to which the unit belongs are extracted. At the same time, the complete type mapping paths corresponding to all operands within the unit are retrieved and integrated to form a type interaction feature combination unique to the expression. Then, the implicit conversion capability difference set between the source library and the target library generated earlier is retrieved. Using the operator, operand source type combination, and function parameter type combination as matching search conditions, difference records with complete matching features are searched within the difference set. If a matching record is found, it means that the expression unit has native implicit conversion capabilities in both the source library and the target library. Upon identifying a deviation in the conversion behavior, the expression unit is immediately determined to be an implicit type conversion risk expression. Simultaneously, the corresponding difference record, type mapping path, and context information are bound as evidence of the risk. After traversing all expression units to complete the matching retrieval, all identified risk expressions are aggregated. Each risk expression retains a complete record of the source of the triggering difference, the type conversion path, and the usage scenario. This accurately locates expression-level drift risks formed solely by combinations of fields, constants, parameters, and operational logic, distinguishing them from basic risks at the single-field type mapping level. This provides precise risk objects for subsequent construction of ternary coverage units and generation of targeted trigger samples.

[0038] Step 30: Generate a set of trigger samples based on the implicit type conversion risk expression to generate a verification statement, and execute the verification statement in the source database and the target database respectively to obtain the execution results of the source database and the target database.

[0039] As an optional embodiment, a set of trigger samples is generated based on the implicit type conversion risk expression to generate a verification statement, and the verification statement is executed in the source database and the target database respectively to obtain the execution results of the source database and the target database. Specifically, it may include: Step 301: Constructing a set of ternary coverage units composed of mapping path, expression context and behavior difference dimension to generate the set of trigger samples.

[0040] In this step, for each identified implicit type conversion risk expression, its corresponding type mapping path and the context scenario to which the expression belongs are extracted. Simultaneously, all possible behavioral differences between the source and target libraries under this scenario are identified. These three elements are bound and combined to form independent ternary coverage units. All ternary coverage units corresponding to all risk expressions are uniformly collected to construct a complete set of ternary coverage units. Each unit in the set represents an independent migration drift risk verification target, distinguishing different type conversion links, usage scenarios, and abnormal behavior manifestations. Based on the coverage requirements of the ternary coverage unit set, candidate trigger samples are generated through multiple channels. Equivalence class samples, boundary anomaly samples, real business data, historical risk samples, and parameter-bound exclusive samples are integrated to form an initial candidate trigger sample set. All candidate samples are labeled with the ternary coverage unit identifiers they can cover, ensuring that the sample generation fully matches the verification target of implicit conversion drift under heterogeneous database migration. This departs from the generalized sample logic of general functional testing, constructing test data specifically around the risk patterns carried by the ternary units, laying a standardized coverage benchmark for subsequent selection of approximately minimum sample sets and reduction of verification overhead.

[0041] Step 302: Based on each trigger sample and its corresponding risk expression in the trigger sample set, generate source database verification statements and target database verification statements, and execute the verification statements respectively to obtain source database execution results and target database execution results containing execution status, number of returned rows, returned column information, return type, return result, exception information, number of affected rows and side effect information.

[0042] In this step, based on the already screened set of trigger samples and the risk expression unit bound to each sample, we construct exclusive verification statements adapted to the syntax specifications of the source and target databases for different scenarios. We construct query verification statements for query-type expressions and corresponding manipulation statements for data modification-type expressions. Temporary storage structures, isolated test environments, or transaction rollback mechanisms can effectively prevent business data pollution. For trigger samples with parameter binding attributes, we synchronously generate parameterized verification logic according to the binding interface and binding type of the sample record. After generating the verification statements for both types of databases, we establish independent database sessions and send the corresponding verification statements to the source and target databases for sequential execution. We collect multi-dimensional execution behavior information throughout the process, including the overall execution status (success or failure) and the completion status after execution. The system returns the number of rows of data, the column information consisting of the column names and number of columns in the result set, the return type output after implicit conversion of the expression, the standardized summary of the return result, the unified exception information categorized under error scenarios, the number of rows affected by changes generated by data manipulation statements, and various side effect information such as triggers, default values, and sequence changes. The system integrates and encapsulates the complete set of information collected from the source database into the source database execution result, and simultaneously encapsulates it into an independent target database execution result. The two sets of results are stored using a unified information structure, completely preserving the full-dimensional behavioral performance of the same sample and the same risk expression in both databases. This eliminates the data fragmentation problem caused by differences in the native output format of the databases, and provides complete and aligned original behavioral data support for subsequent execution result normalization, behavioral fingerprint generation, and drift determination.

[0043] Step 40: Based on the execution results of the source database and the target database, determine whether there is implicit type conversion drift, obtain the behavioral fingerprint differences between the source database and the target database, and determine the cause of drift based on the implicit type conversion risk expression, the trigger sample set, and the behavioral fingerprint differences, so as to generate repair suggestions.

[0044] As an optional embodiment, based on the execution results of the source database and the execution results of the target database, it is determined whether there is implicit type conversion drift, so as to obtain the behavioral fingerprint difference between the source database and the target database, and the drift cause is determined based on the implicit type conversion risk expression, the trigger sample set and the behavioral fingerprint difference to generate a repair suggestion. Specifically, it may include: Step 401: Normalize the execution results of the source database and the execution results of the target database to generate the behavioral fingerprint of the source database and the behavioral fingerprint of the target database.

[0045] In this step, the original differential information of the databases is first mapped and transformed, mapping the unique error codes, type names, times, and structured data output formats of each database to a unified semantic specification, and removing the database-specific text identifiers. Then, the return results, sorting logic, and side effect information are summarized and compressed, and the expression forms of floating-point numbers, time, Boolean, and structured data are standardized, distinguishing the unified exception categories and error stages corresponding to various anomalies. After normalization, all standardized information is integrated according to a unified fixed structure, covering execution status, result summary, column metadata, transformed return type, number of rows affected by changes, standardized exception information, sorting behavior, side effects such as triggers, tolerable difference configurations, and drift level identifiers, and encapsulating them to generate source database behavioral fingerprints and target database behavioral fingerprints. The two types of fingerprints use a completely consistent data architecture, shielding the differences in the output formats of the underlying databases, and transforming the running behavior of the two databases for the same trigger sample into standardized structured data that can be directly compared, providing a unified comparison carrier for subsequent difference calculation, drift classification, and root cause attribution.

[0046] Step 402: Compare the difference types between the source database behavioral fingerprint and the target database behavioral fingerprint item by item, and perform a weighted sum based on the weight coefficients corresponding to the difference types to obtain the drift difference value.

[0047] In this step, the source database behavioral fingerprint and the target database behavioral fingerprint, which are structurally aligned, are compared. Differences are determined item by item according to the pre-defined standardized field dimensions of the fingerprints. Eight types of differences are verified sequentially: execution status, result summary, returned column information, returned type, number of affected rows, standardized anomaly information, sorting behavior, and side effect information. Each dimension with content mismatch is marked. A dedicated weight coefficient is pre-configured for each type of difference dimension. Different types of differences are weighted according to their business impact, and the sum of all weight coefficients remains at a fixed standard. For dimensions marked as having differences, the corresponding weight coefficient is retrieved and included in the calculation; dimensions without differences are not included in the summation. The weight coefficients of all differing dimensions are summed to complete a weighted summation, ultimately obtaining the drift difference value corresponding to the current triggered sample. This value comprehensively quantifies the degree of inconsistency in the overall behavior of the two databases, without relying on text format differences in the original results. It only relies on the standardized difference dimensions of the normalized fingerprint to complete the quantitative assessment, providing a quantifiable basis for subsequent classification into three risk levels: no drift, tolerable drift, and hard drift, based on pre-defined thresholds.

[0048] Step 403: If the drift difference value is greater than the preset difference threshold, then the risk expression is determined to have hard drift.

[0049] Step 404: If the drift difference value is greater than 0 and less than the preset difference threshold, then the risk expression is determined to have a tolerable drift.

[0050] Step 405: If the drift difference value is 0, the risk expression is determined to have no drift, and the determination result is used as the behavioral fingerprint difference.

[0051] In this step, a unified drift judgment difference threshold is pre-configured. This threshold can be flexibly adjusted according to various business scenarios to distinguish implicit conversion semantic deviations of different severity. After completing the weighted summation to obtain the drift difference value corresponding to the current trigger sample, if the calculated drift difference value exceeds the preset difference threshold, it means that the core execution behavior of the current risk expression in the source and target databases is inconsistent beyond the acceptable range of business. The risk expression is directly judged to have hard drift. Such deviations will directly change the execution result of business logic, cause program errors, or cause data statistical distortion. It belongs to high-risk issues that need to be repaired first. If the drift difference value is greater than zero and does not exceed the preset difference threshold, the risk expression is judged to have tolerable drift, indicating that the execution behavior of the two databases is acceptable. Although identifiable differences exist, if the deviation falls within the preset rule's allowable range, these differences are not ignored. Instead, the details of the difference, the corresponding trigger sample, and the matching tolerance rule are fully recorded and retained as a business review prompt for business personnel to confirm whether to accept the deviation. When the drift difference value is equal to zero, it means that the source database behavioral fingerprint and the target database behavioral fingerprint are completely matched across all standardized dimensions, with no behavioral deviation of any kind. The risk expression is then determined to have no drift. The above three-level judgment conclusions are integrated and encapsulated with the original difference information of each dimension, uniformly marked as the behavioral fingerprint difference corresponding to the current trigger sample. The complete difference quantification value, threshold comparison relationship, and drift classification conclusion are retained, providing a standardized judgment basis for subsequent drift root cause attribution and automatic generation of targeted remediation suggestions.

[0052] Step 406: When the risk expression determines that there is hard drift or tolerable drift, extract the execution status difference type, anomaly category difference, return type difference, and result summary difference from the behavioral fingerprint differences.

[0053] In this step, after the risk expression is determined to have hard drift or tolerable drift, the complete behavioral fingerprint difference dataset of the sample is retrieved, and four core difference dimensions are extracted as the basic material for drift attribution. First, the execution state difference type is extracted to distinguish the overall behavioral divergence at the execution level of the two database statements. Second, the anomaly category difference is extracted to capture the mismatch information of anomaly types after unified classification in the execution error scenario. Next, the return type difference is extracted to obtain the relevant records of inconsistent output data types after implicit conversion. Finally, the result summary difference is extracted to retain the deviation information at the result level, such as the return content, sorting, and number of changed rows after normalization. The four types of differences are associated and bound with the type mapping path, ternary coverage unit, trigger sample, and parameter binding context corresponding to the risk expression, and the original fingerprint comparison records of each type of difference are completely saved. The extracted multi-dimensional difference information will serve as the core input for drift root cause inference, accurately locate the cause of implicit conversion drift, and provide complete support for subsequent output of targeted and implementable database migration and repair suggestions.

[0054] Step 407: Match the risk pattern, expression context, change attributes in the mapping path, binding type and binding interface of the risk expression, as well as the execution state difference type, exception category difference, return type difference and result summary difference with the preset attribution rules to determine the cause of drift.

[0055] In this step, multi-dimensional feature information is first integrated as input for attribution matching. This includes the standardized risk pattern corresponding to the risk expression, the execution context of the expression, all semantic change attributes within the type mapping path, the binding type and binding interface of the parameter binding process, and four types of difference content extracted from behavioral fingerprint differences: execution status, exception category, return type, and result summary. A built-in set of preset drift attribution rules is then invoked. Each rule is bound to a unique set of features and a corresponding drift root cause definition. The integrated full set of features and attribution rules are matched and retrieved one by one to identify rule entries that highly match all current features. Through rule matching, the core cause of the drift is accurately located, distinguishing different types of drift causes such as string-numerical conversion, date parsing, null value handling, parameter binding adaptation, and sorting rules. The matched drift cause is bound and stored with the current risk expression, trigger sample, and fingerprint difference information to form a complete attribution record. This provides a standardized judgment basis for generating appropriate SQL, field, and parameter call-level repair suggestions based on the drift root cause.

[0056] Step 408: Generate corresponding repair suggestions based on the cause of drift, and output the repair suggestions in association with the risk expression, the set of triggering samples, and the mapping path.

[0057] In this step, a preset repair strategy template is retrieved based on the matched drift causes. Different drift root causes correspond to differentiated rectification solutions, covering various rectification methods such as explicit type conversion rewriting, field structure adjustment, text format standardization, parameter binding interface replacement, character set and sorting rule adaptation, and null value logic rewriting. This generates targeted repair suggestions adapted to the current scenario. After the repair suggestions are generated, a multi-dimensional association and binding relationship is established, binding and archiving the repair suggestions with the risk expression that caused the drift, the approximate minimum trigger sample set used for verification, and the type mapping path associated with the expression. This completely preserves the risk generation chain, the correspondence between the verification carrier and the rectification solution. The output content integrates drift classification judgment, drift attribution conclusions, a complete set of related materials, and implementable repair guidelines, forming a standardized migration risk report. The complete data binding ensures that after the repair is completed, the original trigger sample set can be directly reused for regression verification without reconstructing test samples, achieving a complete closed loop of risk identification, solution output, and effect verification, reducing the cost of investigating and rectifying implicit conversion risks during heterogeneous database migration.

[0058] The above are embodiments of the method proposed in this application. Based on the same inventive concept, embodiments of this application also provide a semantic drift verification device for heterogeneous database migration, the structure of which is as follows: Figure 2 As shown.

[0059] Figure 2 This is a schematic diagram of the internal structure of a semantic drift verification device for heterogeneous database migration, provided as an embodiment of this application. Figure 2 As shown, the device includes: At least one processor 201; And a memory 202 that is communicatively connected to at least one processor; The memory 202 stores instructions executable by at least one processor. These instructions are executed by at least one processor 201 to enable the processor 201 to: execute implicit transformation capability probe statements on both the source and target databases to obtain probe execution results; generate implicit transformation capability matrices for the source and target databases based on the probe execution results; calculate the difference set between the implicit transformation capability matrices of the source and target databases; and parse structured query language statements and database object definitions in the source and target databases to extract the binding types and binding connections corresponding to expression units and parameter placeholders in the structured query language statements. Based on expression units, binding types, binding interfaces, difference sets, and the mapping paths between the source and target types of each operand, implicit type conversion risk expressions are identified. A trigger sample set is generated based on these implicit type conversion risk expressions to produce verification statements, which are then executed in both the source and target databases to obtain execution results. Based on these results, it is determined whether implicit type conversion drift exists, obtaining behavioral fingerprint differences between the source and target databases. Finally, the cause of the drift is identified based on the implicit type conversion risk expressions, the trigger sample set, and the behavioral fingerprint differences, to generate remediation suggestions.

[0060] Some embodiments of this application provide corresponding to Figure 1 A non-volatile computer storage medium for semantic drift verification of heterogeneous database migration stores computer-executable instructions. These instructions are configured to: execute implicit transformation capability probe statements on both the source and target databases to obtain probe execution results; generate implicit transformation capability matrices for both the source and target databases based on these results; calculate the difference set between the implicit transformation capability matrices of the source and target databases; and parse structured query language statements and database object definitions in both the source and target databases to extract the binding types and binding interfaces corresponding to expression units and parameter placeholders in the structured query language statements. Based on expression units, binding types, binding interfaces, difference sets, and the mapping paths between the source and target types of each operand, implicit type conversion risk expressions are identified. A trigger sample set is generated based on these implicit type conversion risk expressions to produce verification statements, which are then executed in both the source and target databases to obtain execution results. Based on these results, it is determined whether implicit type conversion drift exists, obtaining behavioral fingerprint differences between the source and target databases. Finally, the cause of the drift is identified based on the implicit type conversion risk expressions, the trigger sample set, and the behavioral fingerprint differences, to generate remediation suggestions.

[0061] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for IoT devices and media are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0062] The systems, media, and methods provided in this application are one-to-one correspondences. Therefore, the systems and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the systems and media will not be repeated here.

[0063] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0064] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0065] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0066] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0067] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0068] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0069] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

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

[0071] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A semantic drift verification method for heterogeneous database migration, characterized in that, The method includes: Implicit transformation capability probe statements are executed on both the source and target databases to obtain probe execution results. Based on these results, implicit transformation capability matrices for the source and target databases are generated. The difference set between these matrices is then calculated, specifically including: The implicit transformation capability records corresponding to all probe statements in the source database are summarized into a source database implicit transformation capability matrix, and the implicit transformation capability records corresponding to all probe statements in the target database are summarized into a target database implicit transformation capability matrix. Traverse the records with the same probe identifier and the same probe context in the implicit transformation capability matrix of the source database and the implicit transformation capability matrix of the target database, and compare the differences in execution status, return type, exception category and error stage item by item to generate the difference set; The process involves parsing the Structured Query Language (SCL) statements and database object definitions in the source and target databases to extract the binding types and binding interfaces corresponding to expression units and parameter placeholders in the SCL statements. Based on the expression units, binding types, binding interfaces, difference sets, and the mapping paths between the source and target types of each operand, implicit type conversion risk expressions are identified. Specifically, this includes: Based on the source type of the operands in the expression unit in the source database and the preset type mapping rules, the target type of the operands in the expression unit after migration to the target database is determined, and the changes in numerical range, precision scale, format parsing rules, null value handling rules, validation strictness and sorting rules between the source type and the target type are recorded to construct a mapping path; Based on the operator or function name contained in the expression unit, the expression context to which the expression unit belongs, and the mapping path of each operand, the difference record that matches the combination of operator, operand source type, or function input parameter type in the difference set is searched to obtain the implicit type conversion risk expression. A set of trigger samples is generated based on the implicit type conversion risk expression to generate a verification statement. The verification statement is then executed in the source database and the target database respectively to obtain the execution results of the source database and the target database. Based on the execution results of the source database and the target database, it is determined whether implicit type conversion drift exists, so as to obtain the behavioral fingerprint difference between the source database and the target database. Based on the implicit type conversion risk expression, the trigger sample set and the behavioral fingerprint difference, the drift cause is determined to generate a repair suggestion. Based on the execution results of the source database and the target database, it is determined whether implicit type conversion drift exists, in order to obtain the behavioral fingerprint differences between the source database and the target database, specifically including: The execution results of the source database and the target database are normalized to generate behavioral fingerprints of the source database and the target database. The source database behavioral fingerprint and the target database behavioral fingerprint are compared item by item for differences in type, and a weighted sum is performed based on the weight coefficients corresponding to the difference type to obtain the drift difference value; wherein, the difference type includes execution status difference, return row number difference, return type difference, result summary difference, sorting summary difference, anomaly category difference, error stage difference, affected row number difference, and side effect difference; If the drift difference value is greater than a preset difference threshold, then the risk expression is determined to have a hard drift. If the drift difference value is greater than 0 and less than the preset difference threshold, then the risk expression is determined to have a tolerable drift. If the drift difference value is 0, the risk expression is determined to have no drift, and the above three-level judgment conclusions are integrated and encapsulated with the original difference information of each dimension, and uniformly marked as the behavioral fingerprint difference corresponding to the current trigger sample.

2. The semantic drift verification method for heterogeneous database migration according to claim 1, characterized in that, Execute implicit transformation capability probe statements on both the source and target databases to obtain the probe execution results, specifically including: The implicit transformation capability probe statements corresponding to the source database and the target database are selected from the preset probe template library and executed to obtain the probe execution results; wherein, the probe statements include comparison probes, assignment probes, function input parameter probes, arithmetic operation probes, date parsing probes, verification probes, time interval parsing probes, null probes and sorting rule probes; the probe execution results include execution status, return type, exception category and error stage.

3. The semantic drift verification method for heterogeneous database migration according to claim 1, characterized in that, Parsing the Structured Query Language (SCL) statements and database object definitions in the source and target databases to extract expression units and the binding types and binding interfaces corresponding to parameter placeholders in the SCL statements, specifically including: Lexical and syntactic analysis are performed on the structured query language statement and the database object definition to generate an expression tree; Traverse the expression tree to extract syntactic structures containing fields, constants, parameter placeholders or function calls, and operators or function names as expression units, and record the expression context to which the expression unit belongs; Extract the parameter numbers of each parameter placeholder in the structured query language statement, and determine the binding type and binding interface corresponding to each parameter number based on the binding configuration or driver logs collected by the application. Then associate the binding type and the binding interface with the corresponding parameter placeholder.

4. The semantic drift verification method for heterogeneous database migration according to claim 3, characterized in that, A set of trigger samples is generated based on the implicit type conversion risk expression to generate a verification statement. The verification statement is then executed in both the source database and the target database to obtain execution results for the source database and the target database, respectively. Specifically, this includes: Construct a set of ternary coverage units consisting of the mapping path, the expression context, and the behavior difference dimension to generate a set of trigger samples; Based on each trigger sample and its corresponding risk expression in the trigger sample set, a source database verification statement and a target database verification statement are generated and executed respectively to obtain the source database execution result and the target database execution result, which include execution status, number of returned rows, information on returned columns, return type, return result, exception information, number of affected rows, and side effect information.

5. A semantic drift verification method for heterogeneous database migration according to claim 3, characterized in that, The cause of drift is determined based on the implicit type conversion risk expression, the trigger sample set, and the behavioral fingerprint differences, in order to generate a repair suggestion, specifically including: When the risk expression is determined to have hard drift or tolerable drift, the execution state difference type, anomaly category difference, return type difference and result summary difference are extracted from the behavioral fingerprint differences. The risk pattern of the risk expression, the expression context, the change attributes in the mapping path, the binding type and the binding interface, as well as the execution state difference type, the exception category difference, the return type difference, and the result summary difference are matched with preset attribution rules to determine the cause of drift. The causes of drift include implicit conversion differences between strings and numbers, date and time format parsing differences, numerical range shrinkage differences, validation rule differences, time interval format parsing differences, null value and empty string processing differences, function input parameter type matching differences, sorting rule differences, and implicit conversion differences caused by parameter binding types. Based on the cause of the drift, a corresponding repair suggestion is generated, and the repair suggestion is associated with the risk expression, the set of triggering samples, and the mapping path and output.

6. A semantic drift verification device for heterogeneous database migration, characterized in that, The device includes: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the method as described in any one of claims 1-5.

7. A non-volatile computer storage medium for semantic drift verification of heterogeneous database migration, storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed, they implement the method as described in any one of claims 1-5.

Images