Hi Christophe, As I previously explained, there's no need for a roundtrip or different transactions levels.
If you fetch N+1 items you know if there are over N items in your list. So with that in mind you can simply do a query with a limit of N+1 to know if your query returns over N items. No need for different isolation modes or extra statements, the only cost is that instead of a maximum of 10,000 items you will be fetching 10,001 items iff. there is no limit currently defined for the query. As for this being a bug in the application instead of Django, I fully agree. But it can be very difficult to debug issues like these if at some random moment the entire server crashes. - Limiting the memory usage for the application doesn't help in debugging since it will just kill the Django app without a proper stacktrace. - In some cases you are unable to limit the resources on a server level and you'll just have to watch the entire machine die The proposed solution is simply a safety net to prevent a complete server from dying completely, it doesn't even have to be a default option but it's one that I would like to have to make debugging easier and to protect servers from dying without any traceable cause as the resource starvation can kill the machine without ever showing anything useful in the logs. On 24 November 2014 at 12:16, Christophe Pettus <x...@thebuild.com> wrote: > > 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 a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/aYwPykvLaMU/unsubscribe > . > To unsubscribe from this group and all its topics, 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. > -- 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/CAJAwA%3Dw58khSiRrWPXM3fjxXLvs6ON8An3UFf_UvZf%3DBUv8rGg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
