Regardless of whatever comments and corrections may come, I thank you for
summarizing what you think the changes will be! I didn't know about these
impending changes.
John
On May 21, 2013, at 4:23 AM, Michael <mich...@d3i.com> wrote:
>
> I've been reading up on how transactions work in Django 1.5 and how they will
> work in 1.6. I think I have a grasp of things, but I wanted to reach out on
> here to just check that my understanding of things is correct, and ask a
> question or two.
>
> Django 1.5:
>
> The database-level auto-commit is turned OFF.
> SQL standards dictate that every query opens a transaction if one does not
> already exist. This happens regardless of the database's auto-commit setting.
> After each Django ORM operation (read or write), Django commits this open
> transaction. This emulates the database-level auto-commit.
> Transaction decorators cannot be nested. When one is opened, any previous
> transaction will be committed.
> When executing raw SQL (with a database cursor), Django marks the current
> transaction as dirty but does not issue a commit. If data changes were made
> then they need manually committing. Why do the docs say that you only need to
> commit the change if data was changed? If the transaction is marked as dirty
> regardless of a read or a write, would it not always need committing or
> rolling back to ensure the transaction is properly closed by the end of the
> connection?
> Setting TRANSACTIONS_MANAGED to True stops Django from sending any commits
> after ORM operations. The database-level auto-commit is still disabled. With
> this setting, using any Django ORM read or write operation (all wrapped in
> `transaction.commit_on_success`) fails with TransactionManagementError('This
> code isn't under transaction management'). Is this expected?
> Django 1.6:
>
> The database-level auto-commit is turned ON.
> Every database operation via the ORM will be committed using the database's
> auto-commit, including any custom SQL executed with the database cursor.
> The `atomic` decorator / context manager either starts a new transaction, or
> creates a new savepoint if it's nested within an existing transaction. They
> are committed as long as no exception is raised.
> If ATOMIC_REQUESTS is specified in the database config, all views are wrapped
> in `atomic`, unless it's wrapped in `non_atomic_requests`.
> If you set AUTOCOMMIT to False in a database configuration, this will disable
> the database-level auto-commit. All DB reads and writes will need manually
> wrapping in transactions. The docs say that with this disabled, Django won't
> perform any commits. Does this mean that the `atomic` decorator won't work
> properly and you have to use the underlying database library to handle
> transactions? In 1.6 it would appear that Django never performs a commit
> outside of `atomic`, so I'm confused by this comment!
> I'd really appreciate any information if some of what I understand to be true
> is not accurate.
>
> Many thanks!
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
