-
Notifications
You must be signed in to change notification settings - Fork 27
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
Mimic sqlite3 standard module Type extensions to DB-API #9
Conversation
The DB-API says the "return values are not defined", then is better to stick with the sqlite3 module behaviour
Question: on |
@alanjds -- would you mind opening an issue in the rqlite repo for your question? |
@alanjds -- when you say it's better than before (I don't doubt you) do you mean there is more functionality, and more tests pass? Also, should we skip the tests that are failing? |
Oops, just forgot to put a default on connections, unless all tests will fail. |
When I saw a DB-API driver for a distributed version of SQLite then I expected it to be feature-compatible with some caveats, not to implement just the minimal API to be considered PEP249-compliant. Be clear that it is not a rant, just expectations mismatch. Then I updated the driver to be as compliant as possible with the standard sqlite3 API, that I did not knew to be not standard. It is non-standard because have extensions to work around sqlite3 lack of features like BOOL type, etc. The first time I expected pyrqlite to be an almost drop-in replacement of sqlite3, and this PR is the far I could came to fulfil this expectation for the next guy trying.
|
Provides a
dbapi.py
API as close as possible from stock sqlite3 module Type extensions of stdlib of Python.Imported
test_types.py
tests from https://github.com/ghaering/pysqlite.For now, one suite (CTE) is disabled and 2 tests fails, mainly about custom types combined with Unicode conversion:
But anyway is a lot better (more compatible) than before ;)