On Nov 24, 2014, at 1:08 AM, Rick van Hattem <wo...@wol.ph> wrote: > Indeed, except it's not an "except: pass" but an "except: raise" which I'm > proposing. Which makes a world of difference.
Well, as previously noted, this option would introduce another round-trip into every database if it's actually going to check (and, in most databases, would have to run inside a transaction at, at least, REPEATABLE READ isolation mode in order to provide a strong guarantee, so you can add three more statements to a lot of interactions right there). That seems to reduce the "high performance" part of the system. What I'm getting at is: This is a bug in the application. It's not a misfeature in Django. If you have a bug in an application whose source code cannot be changed, that's a shame, but I don't think that Django can be expected to introduce configuration options to cover every possible scenario in which a previously-written Django application interacts badly with the database in a way in which, in theory, it could do extra work (slowing down non-buggy applications and introducing more code to QA) to patch the bad application. To me, this is about as logical as putting in DIVIDE_BY_ZERO_RETURNS_NONE with a default of False because someone wrote some legacy code that would work if we did that. -- -- Christophe Pettus x...@thebuild.com -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/C28E966C-8DB6-4E9D-BDBA-F30C7708EBBE%40thebuild.com. For more options, visit https://groups.google.com/d/optout.
