Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

database/sql: think about a std error / informational messages #19797

Open
kardianos opened this issue Mar 30, 2017 · 4 comments
Open

database/sql: think about a std error / informational messages #19797

kardianos opened this issue Mar 30, 2017 · 4 comments
Assignees
Labels
Milestone

Comments

@kardianos
Copy link
Contributor

@kardianos kardianos commented Mar 30, 2017

Many databases support returning multiple errors, with each error containing a line number, text, and numeric code. I want to explore what it would take to define a standard error interface that could be used to unpack this information. A concrete use case is to 1000 line SQL block that errored, then show just the context of the portions where it errored. A concrete use case for getting the error code is when a user raises a user error, it is often useful to distinguish this from a SQL syntax error. You may wish to abort a query early within the SQL text and only in that condition expose the user to the underlying message, but in the case of generic SQL errors, hide or retry them.

In a similar way, Postgresql, MS SQL, and Oracle all support the concept of streaming messages while the query is running. This is less of an issue, but still might be useful. Fewer concrete uses for messages in SQL.

@kardianos kardianos added the Thinking label Mar 30, 2017
@kardianos kardianos added this to the Unplanned milestone Mar 30, 2017
@kardianos kardianos self-assigned this Mar 30, 2017
@kardianos

This comment has been minimized.

Copy link
Contributor Author

@kardianos kardianos commented Mar 31, 2017

I don't really have a concrete use for Messages. I'm going to put that thought on hold.

I'm going to proceed looking into this and determine if a common sql error interface makes sense. If I think it does I'll define it initially outside the std lib. If it gets use I'll propose adding it in.

@kevinburke

This comment has been minimized.

Copy link
Contributor

@kevinburke kevinburke commented Apr 3, 2017

Here's a package I wrote to solve a similar problem, which was that the native error messages returned by Postgres really weren't appropriate for exposing to end users. https://github.com/Shyp/go-dberror

I also had the library export common error codes, like unique constraint failure, not null violation, etc. It's a problem that those are different on different database engines and I'm not sure how to resolve that.

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Apr 3, 2017

CL https://golang.org/cl/39355 mentions this issue.

kardianos added a commit to golang-sql/sqlexp that referenced this issue Apr 28, 2017
Drivers ususally hide the details of messages
from the server. Most clients don't care about details
or include complex SQL with multiple statements. Many still
do care about these details. Provide a way to dequeue messages
from the driver.

Relies on go1.9 ( https://golang.org/cl/38533 ).

Updates golang/go#19797
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented May 8, 2017

CL https://golang.org/cl/38533 mentions this issue.

gopherbot pushed a commit that referenced this issue May 18, 2017
Previously all arguments were passed through driver.IsValid.
This checked arguments against a few fundamental go types and
prevented others from being passed in as arguments.

The new interface driver.NamedValueChecker may be implemented
by both driver.Stmt and driver.Conn. This allows
this new interface to completely supersede the
driver.ColumnConverter interface as it can be used for
checking arguments known to a prepared statement and
arbitrary query arguments. The NamedValueChecker may be
skipped with driver.ErrSkip after all special cases are
exhausted to use the default argument converter.

In addition if driver.ErrRemoveArgument is returned
the argument will not be passed to the query at all,
useful for passing in driver specific per-query options.

Add a canonical Out argument wrapper to be passed
to OUTPUT parameters. This will unify checks that need to
be written in the NameValueChecker.

The statement number check is also moved to the argument
converter so the NamedValueChecker may remove arguments
passed to the query.

Fixes #13567
Fixes #18079
Updates #18417
Updates #17834
Updates #16235
Updates #13067
Updates #19797

Change-Id: I89088bd9cca4596a48bba37bfd20d987453ef237
Reviewed-on: https://go-review.googlesource.com/38533
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.