Aymeric Augustin added the comment:
> The idea was to not take away from what's there already: The sqlite3 module
> already has a feature to inspect a command and begin or commit automatically.
> Just stripping that away *removes* a feature that has been available for a
> long time. I'd rather give the
client more control instead of less and let him fine tune this behaviour.
For the sake of clarity, I haven't proposed to remove anything. I'm focusing on
preserving the same behavior by default (with its advantages and drawbacks) and
providing more control for users who need a different behavior, for instance
people who use SQLite as an application file format or as a web application
storage backend.
> When starting with Python I always thought that code like this is harmles:
>>> conn = sqlite3.connect("test.db")
>>> data = list(conn.execute("select * from mytable"))
> Currently it is, but only because sqlite3 module parses the select as DQL and
> does not lock the database.
It will absolutely remain harmless with my proposal, if you don't change your
code.
However, for that use case I would like to encourage the use of autocommit
mode. That's really the semantics you want here.
In fact, you've written several sentences along the lines "currently we have
$ADVANTAGE". It's easy to (mis)interpret that as implying that I'm trying to
remove these advantages. But that's simply not true.
To sum up, if I understand correctly, in_transaction gives you the ability to
fight the behavior mandated by the DB API in client code, because you
understand it well.
My take is to avoid the problem entirely, and not inflict it to new users, by
providing an option to start in autocommit mode and then create transactions
only when you want them.
The DB API doesn't forbid this option. It just prevents it from being the
default (even though it's what the average developer expects).
It solves the problem of using SQLite as an application file format. Use
autocommit as long as you're just reading; start a transaction before writing;
commit when you're done writing.
Of course, that only applies to new software. Existing software can happily
keep using the current behavior, which will be preserved at least for the
lifetime of Python 3.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
