gh-100414: Add SQLite backend to dbm by erlend-aasland · Pull Request #114481 · python/cpython (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation82 Commits48 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
I suggest to focus this PR on the basic, required functionality only. We can optimise things in follow-up PRs.
I think the basic functionality is ready for an initial round of reviews.
Tests
There's a basic test suite in Lib/test_dbm.py
, and I also added some dbm.sqlite3
specific tests in Lib/test_dbm_sqlite3.py
. We can expand the latter in follow-up PRs.
Docs
I also added som basic docs; unless significant information is missing, I suggest we work on the docs in follow-up PRs.
…ILD_TABLE never can raise a DB API exception
I made a core dev poll on Discourse regarding if the SQLite backend should be the default one; 16 out of 21 was in favour (Skip changed his mind post voting). This PR does not make the SQLite backend the default. If we want to change the default, we can do it post merging the feature itself. Another possibility, suggested by @ethanfurman:
Shouldn’t we make it the default now so it can be tested in the alphas? We can undo the default portion if it turns out to be a problem.
@serhiy-storchaka, should we land this?
It seems that currently it is not compatible with other dbm implementations. They all are bytes oriented, but accept strings as input (it is a Python 2 legacy). Most of the dbm tests use string input, so I expect that many user code does it too. But the output always expected to be bytes.
Supporting other types, supported by Sqlite looks attractive, but we implement a backend to dbm, so it should be compatible. We can later add an option to alter the behavior, but it should not be default.
It seems that currently it is not compatible with other dbm implementations. They all are bytes oriented, but accept strings as input (it is a Python 2 legacy). Most of the dbm tests use string input, so I expect that many user code does it too. But the output always expected to be bytes.
Supporting other types, supported by Sqlite looks attractive, but we implement a backend to dbm, so it should be compatible. We can later add an option to alter the behavior, but it should not be default.
As discussed in DM, I agree with this. I addressed your concern in e782fad.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM if all operations still accept strings.
# (raw, coerced) |
---|
(42, b"42"), |
(3.14, b"3.14"), |
("string", b"string"), |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it work with non-ASCII strings?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean such a test?
diff --git a/Lib/test/test_dbm_sqlite3.py b/Lib/test/test_dbm_sqlite3.py index 7bc2a03035..3d2dc5fd55 100644 --- a/Lib/test/test_dbm_sqlite3.py +++ b/Lib/test/test_dbm_sqlite3.py @@ -214,6 +214,7 @@ class DataTypes(_SQLiteDbmTests): (3.14, b"3.14"), ("string", b"string"), (b"bytes", b"bytes"),
("æøå", b"\xc3\xa6\xc3\xb8\xc3\xa5"),
)
def setUp(self):
With 34930cb, the dbm.sqlite3 backend now aligns with the other backends; for example, the general code snippet in the dbm docs now works as expected with the new backend.
Let's land this, @serhiy-storchaka. There is plenty of opportunities to tweak the implementation and to expand the test suite.
Thanks @smontanaro for the initial idea, @rhettinger for the initial implementation, and everyone else involved for ideas, reviews and critique. Thanks to @serhiy-storchaka for the, as always, extremely thorough review of the feature and the implementation.
This comment was marked as resolved.
This comment was marked as duplicate.
This comment was marked as duplicate.
erlend-aasland added a commit to erlend-aasland/cpython that referenced this pull request
This comment was marked as resolved.
fsc-eriker pushed a commit to fsc-eriker/cpython that referenced this pull request
Co-authored-by: Raymond Hettinger rhettinger@users.noreply.github.com Co-authored-by: Serhiy Storchaka storchaka@gmail.com Co-authored-by: Mariusz Felisiak felisiak.mariusz@gmail.com
Reviewers
gpshead gpshead left review comments
presidento presidento left review comments
felixxm felixxm left review comments
corona10 corona10 approved these changes
serhiy-storchaka serhiy-storchaka approved these changes
rhettinger Awaiting requested review from rhettinger
berkerpeksag Awaiting requested review from berkerpeksag berkerpeksag is a code owner