#24921: No Database objects can be created with set_autocommit(False)
-------------------------------+--------------------------------------
Reporter: shabda | Owner: shabda
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.8
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Comment (by carljm):
I think you could probably actually use `transaction.atomic`, if lettuce
gives you a place to stash some state between the hooks. You'd just call
it, get an `Atomic` object back, and then manually call its `__enter__`
and `__exit__` methods.
It seems to me that there is a valid use case here ("manual transaction
control when the code structure, probably because of some other library,
won't allow for a context manager or or decorator as the code idiom"), and
I don't think the workaround I've suggested above is really adequate API
for that use case.
Currently our documentation strongly suggests that the right approach for
this case is `set_autocommit(False)` followed by commit or rollback. If
the ORM is completely nonfunctional in that scenario (not just "doesn't
handle transactions for you", but completely unusable), then I do think
that's a problem that should be fixed.
I guess it could be that the right fix is a new higher-level API on a
similar level to `atomic`, but that is usable as separate function calls
instead of a context manager or decorator.
But it also seems to me that the ORM _should_ be able to basically
function with autocommit off (even if it handles transactions
unpredictably), and that this bug that prevents it from working does not
look unsolvable. If it turns out that we can't fix it, then I definitely
think we need _much_ stronger warnings in the docs (along the lines of
"these APIs documented below are only usable with raw SQL, you cannot use
the ORM at all"), and I think we probably also should suggest a reasonable
alternative approach for non-context-manager transaction control with a
usable ORM.
--
Ticket URL: <https://code.djangoproject.com/ticket/24921#comment:8>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/064.af26e1321e39e4e1b5e33a37989b7219%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
