Declarative Query Error Attribution Through Origin Mapping
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional database systems require significant user effort to analyze complex execution plans to identify the root cause of runtime errors in declarative database queries, defeating the purpose of using declarative languages by exposing procedural details.
Innovation Solution
A data processing service attributes runtime errors by identifying the specific portion of the database query that causes the error, maintaining origin information through query transformations, and reporting the root cause alongside the error.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional error reporting mechanisms are used, then error codes can be returned, but significant user analysis effort is required to determine root cause
Solution Approach 1:
The patent introduces an intermediary mapping mechanism that translates execution plan nodes (procedural details) back to declarative query statements. This mediator layer connects the error information in the execution plan to the user-friendly declarative query syntax, allowing automatic root cause identification without requiring users to analyze complex execution plans manually.
Solution Approach 2:
The system implements feedback by tracking the origin of each execution plan node back to its corresponding declarative query statement. When an error occurs during execution, the system uses this feedback mechanism to automatically identify and report the root cause in the original query syntax, eliminating the need for users to trace through complex execution plans.
2Measurement precision
If execution plans are provided for error analysis, then root cause can be identified, but execution plans are complex and difficult to analyze
Solution Approach 1:
Instead of presenting users with complex execution plans and requiring them to analyze procedural details, the patent inverts the approach by automatically translating error information back into the declarative query syntax. This inversion transforms the analysis task from examining complex execution plans to reviewing simple, user-friendly query statements where the root cause is immediately visible.
Solution Approach 2:
The system creates a copy or representation of the execution plan nodes in terms of the original declarative query syntax. This copied representation maintains the essential error location information while presenting it in a format that is easy for users to understand and analyze, eliminating the need to interpret complex execution plan structures.
3Ease of operation
If declarative query language is used, then user-friendly query specification is achieved, but procedural details are hidden making error analysis difficult
Solution Approach 1:
The patent segments the query processing into distinct components: the declarative query statement (user-friendly specification) and the execution plan (procedural implementation). By maintaining segmentable origin information that maps between these two layers, the system preserves the ease of declarative query specification while enabling precise error detection in the procedural execution layer.
Solution Approach 2:
The system introduces an intermediary mapping layer that connects the declarative query syntax with the execution plan. This intermediary maintains the benefits of declarative query specification while providing a bridge to error detection mechanisms, allowing the system to detect errors in procedural execution and present them in the user-friendly declarative syntax.
Data Source
AI summary
A device may receive, from a user interface of a client device, a database query specified using a declarative database query language. A device may generate code based on the database query, wherein the generated code represents sets of instructions for executing the database query. A device may generate an error attribution mapping that maps sets of instructions to origins of the sets of instructions, wherein the error attribution mapping is filtered by eliminating one or more origins from the error attribution mapping. A device may determine a runtime error caused by executing the generated code. A device may identify one or more origins of the runtime error in the database query based on the error attribution mapping. A device may display information describing the one or more origins of the runtime error on the user interface of the client device.