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

bpo-16379: Expose sqlite error code #1108

Closed

Conversation

palaviv
Copy link
Contributor

@palaviv palaviv commented Apr 13, 2017

This PR adds the sqlite error code and name to the exceptions raised by the sqlite3 module. Once this is merged my hope is to expose the sqlite extended error code as discussed in bpo-24139

https://bugs.python.org/issue16379

Copy link

@auvipy auvipy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

plz rebase!

@matrixise matrixise changed the title bpo-16379: Expose sqlite error code bpo-16379: Expose sqlite error code May 7, 2019
@matrixise
Copy link
Member

Hi @palaviv

Would you be interested to upgrade your PR to the last master?

Thank you

@matrixise matrixise requested a review from berkerpeksag May 7, 2019 20:48
@palaviv palaviv force-pushed the bpo-16379-expose-sqlite-error-code branch from 365ad2a to c236045 Compare May 8, 2019 12:22
@palaviv
Copy link
Contributor Author

palaviv commented May 8, 2019

Sure @matrixise. Do you think there is a chance for this to be merged?

@palaviv palaviv force-pushed the bpo-16379-expose-sqlite-error-code branch from b9dc556 to 31467e3 Compare May 9, 2019 09:55
@dimaqq
Copy link
Contributor

dimaqq commented Jun 7, 2019

If I remember https://bugs.python.org/issue24139 correctly, the issue was rather about exposing the extended error codes http://www.sqlite.org/c3ref/c_abort_rollback.html

@palaviv
Copy link
Contributor Author

palaviv commented Jun 11, 2019

@dimaqq you are correct. This is a patch for https://bugs.python.org/issue16379. There is a different patch that depends on this change to solve https://bugs.python.org/issue24139.

@danielepusceddu
Copy link

I'd really really like to have this feature...

static const IntConstantPair _int_constants[] = {
{"PARSE_DECLTYPES", PARSE_DECLTYPES},
{"PARSE_COLNAMES", PARSE_COLNAMES},

{"SQLITE_OK", SQLITE_OK},
/* enumerated return values for sqlite3_set_authorizer() callback */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like SQLITE_OK is used in the wild (https://github.com/search?l=Python&p=4&q=SQLITE_OK&type=Code) thus it cannot be removed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SQLITE_OK is definitely in use. For example, it is used one of the valid return values in authoriser callbacks.

#ifdef SQLITE_NOTADB
{"SQLITE_NOTADB", SQLITE_NOTADB},
#endif
{"SQLITE_DONE", SQLITE_DONE},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @palaviv, thanks for picking this up. Should SQLITE_NOTICE and SQLITE_WARNING be added to this list?

@erlend-aasland
Copy link
Contributor

@palaviv: Can you rebase onto master and update your code to PEP 7 standards? Also, the #ifdefs are not needed as SQLite 3.7.15 is now a hard requirement.

@erlend-aasland
Copy link
Contributor

@palaviv, are you planning on landing this PR? If not, would you mind if I reopened a PR with your changes cherry-picked onto it?

@erlend-aasland
Copy link
Contributor

Closing this, as #27786 (based off of this PR) has now been merged. Thank you for your work, @palaviv!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting core review type-feature A feature request or enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.