-
Notifications
You must be signed in to change notification settings - Fork 24
Description
Summary
As an ETL Helper user, I want access to the individual parameters of a query error, so that I can further process them.
Description
We currently have ETLHelperQueryError, ETLHelperExtractError, ETLHelperInsertError that can be thrown if there is a problem with a SQL query.
In each case where they are used, they are supplied with a message constructed as follows:
msg = (f"SQL query raised an error.\n\n{select_query}\n\n"
f"Required paramstyle: {helper.paramstyle}\n\n{exc}\n")
raise ETLHelperExtractError(msg)
The message is helpful, however the individual parameters are not accessible.
The ETLHelperQueryError should take the query
, the database_error_message
and the helper
as parameters.
It should store the first two as attributes, and extract the paramstyle and database type from the helper
and store those as attributes, too.
They can then be accessed for further processing.
The repr or str of the class should be modified so that it appears as an error message similar to:
Error executing SQL query against _sqlite_ database with paramstyle _qmark_.
Query:
SELECT * FROM hello
Error message from database:
bad table
ExtractError and InsertError should be subclasses of QueryError, so that they inherit the same behaviour.
Acceptance criteria
- ETLHelperQuery error stores additional parameters described above
- ETL functions are updated to use new constructor
- Error message looks similar to before, with updated style as above
- ExtractError and InsertError are subclasses of QueryError
- Tests cover parameter extraction
- Documentation is updated to explain class hierarchy and parameter access