Re: [Django] #14970: Inconsistency in handling of managed/unmanaged transactions

[Django]

#14970: Inconsistency in handling of managed/unmanaged transactions
-+-
 Reporter:  mwrobel  |Owner:  aaugustin
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Aymeric Augustin ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"14cddf51c5f001bb426ce7f7a83fdc52c8d8aee9"]:
 {{{
 #!CommitTicketReference repository=""
 revision="14cddf51c5f001bb426ce7f7a83fdc52c8d8aee9"
 Merged branch 'database-level-autocommit'.

 Fixed #2227: `atomic` supports nesting.
 Fixed #6623: `commit_manually` is deprecated and `atomic` doesn't suffer
 from this defect.
 Fixed #8320: the problem wasn't identified, but the legacy transaction
 management is deprecated.
 Fixed #10744: the problem wasn't identified, but the legacy transaction
 management is deprecated.
 Fixed #10813: since autocommit is enabled, it isn't necessary to rollback
 after errors any more.
 Fixed #13742: savepoints are now implemented for SQLite.
 Fixed #13870: transaction management in long running processes isn't a
 problem any more, and it's documented.
 Fixed #14970: while it digresses on transaction management, this ticket
 essentially asks for autocommit on PostgreSQL.
 Fixed #15694: `atomic` supports nesting.
 Fixed #17887: autocommit makes it impossible for a connection to stay
 "idle of transaction".
 }}}

-- 
Ticket URL: 
Django 
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 django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Django] #14970: Inconsistency in handling of managed/unmanaged transactions

[Django]

#14970: Inconsistency in handling of managed/unmanaged transactions
-+-
   Reporter:  mwrobel|Owner:  nobody
   Type:  New|   Status:  new
  feature|Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.2| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-
Changes (by anonymous):

 * type:   => New feature
 * severity:   => Normal


Comment:

 marking as new feature due to backward-compatibility concerns.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14970: Inconsistency in handling of managed/unmanaged transactions

[Django]

#14970: Inconsistency in handling of managed/unmanaged transactions
---+
  Reporter:  mwrobel   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Accepting, because what you describe makes sense.

 However, backwards compatibility can't be ignored here. Transactions are
 one of those areas where very subtle changes in behavior have the
 potential to wreak havoc in live systems. I haven't sat down to fully work
 out the potential impact of what you're proposing, but before anything is
 committed, I'll need to see a very detailed analysis of any potential
 impact. The interaction with Postgres is particularly important, because
 the _enter_transaction_managmeent call on the backend exists for the
 benefit of Postgres.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #14970: Inconsistency in handling of managed/unmanaged transactions

[Django]

#14970: Inconsistency in handling of managed/unmanaged transactions
--+-
 Reporter:  mwrobel   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I think that there are some bugs in the way the 'managed' flag is handled
 in enter_transaction_management() and leave_transaction_management() in
 django/db/transaction.py.

 1. enter_transaction_management() has a 'managed' parameter. I guess it
 should set the new transaction in managed mode depending on the value of
 this parameter, but it takes the mode from the surrounding transaction or
 from the settings (as stated in a comment). Surprisingly,
 connection._enter_transaction_management() is called with the value of the
 'managed' parameter instead of the mode that is set for the new
 transaction.

 2. leave_transaction_management() calls
 connection._leave_transaction_management() passing the mode of the current
 transaction (the transaction that is being left) as a parameter. From what
 I can see in django/db/backends/postgresql_psycopg2/base.py, it expects to
 get the mode of the transaction that will be active after
 leave_transaction_management() finishes.

 Now I will describe the use case in which I encountered the problems: I
 use the psycopg2 backend and I want to have the connection in database-
 level autocommit mode by default. Sometimes I want to begin a managed
 transaction and after some operations commit or rollback it and return to
 the database-level autocommit mode.

 Currently I have to enter the transaction as follows:
 {{{
 enter_transaction_management(managed=True)
 managed(True)
 }}}
 and leave:
 {{{
 managed(False)
 leave_transaction_management()
 }}}

 I think that the managed() calls should be redundant, but the first/second
 one is needed to circumvent the first/second problem I mentioned.

 My proposal is to:

 1. change enter_transaction_management() to set mode depending on the
 parameter (and when parameter is not given, take the mode from the
 surrounding transaction or the settings).

 2. change leave_transaction_management() to pass the mode of the
 transaction that becomes active to
 connection._leave_transaction_management() (I don't know what was the
 intended semantics, but it is what pycopg2 backend seems to expect, and
 other backends don't override _leave_transaction_management()).

 I see that the proposed changes can break backward compatibility, but I
 think that they don't change any documented behavior.

 I can create patches that fix the problem, but I would like to hear from
 Django developers if the fix is acceptable before I write the patches.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.