#3460: postgresql_psycopg2 backend uses wrong isolation level
-------------------------------------------------+--------------------------
   Reporter:  Jack Moffitt <[EMAIL PROTECTED]>  |                Owner:  nobody 
               
     Status:  closed                             |            Component:  
Database wrapper      
    Version:  SVN                                |           Resolution:  
duplicate             
   Keywords:                                     |                Stage:  
Design decision needed
  Has_patch:  1                                  |           Needs_docs:  0     
                
Needs_tests:  0                                  |   Needs_better_patch:  1     
                
-------------------------------------------------+--------------------------
Comment (by Jack Moffitt <[EMAIL PROTECTED]>):

 I see no use case for an application that needs behavior different than
 this.  In this patch, you always know exactly when and how you are in a
 transaction, and you can choose whether your code executes in one or not.
 The old way does not allow this flexibility and always puts you in a
 transaction, which for 90% of the most common queries wastes a lot of
 database cycles.  Any site running stock django with postgresql will be
 crippled by this when it starts to get any load.

 This is not something that is solved by #6064, or at least I think doing
 it that way would be more of a hack.  Solving it by setting the default
 isolation level consistently means that everyone will understand exactly
 how the database is getting used.  It won't be broken for most people
 until they figure out there is some special initializer that magically
 fixes things by changing how all the isolation levels work.  I suppose you
 could make the default initializer do this, but note that this is a lot
 more technical and low level that making sure the time zone is correct or
 setting how postgres returns the date, etc.  There's a reason that this
 functionality is provided _at the wrapper layer_ and the other is provided
 in the SQL language.

 We have at least 3 reports here of people who need this functionality, and
 so far, no reports or explanation on how this functionality would be bad.
 Please reconsider this patch.

-- 
Ticket URL: <http://code.djangoproject.com/ticket/3460#comment:12>
Django Code <http://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 post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to