Re: Sealing or locking QuerySets -- a suggestion to prevent surprise N+1 queries.

Regarding auto prefetch, after the discussion here I created a ticket https://code.djangoproject.com/ticket/28586 It didn't get much attention presumably because it was around Django 2 release time. I have a todo note to add tests and doco and generally get it to a mergable state in order to pus

Re: Sealing or locking QuerySets -- a suggestion to prevent surprise N+1 queries.

I wasn't aware of this new feature Shai, thanks for pointing it out! For this particular case I'd prefer locking to be bound to a particular queryset rather than the database as a whole. I would also expect it to fail loudly when accessing a non-fetched related object (book.author), which can b

Re: Sealing or locking QuerySets -- a suggestion to prevent surprise N+1 queries.

Shai, `execute_wrapper` can be useful to prevent any queries from happening at all but I believe there's merit in wanting to prevent objects retrieved from a queryset from executing ghost queries during manipulations of the returned `Model` instances while allowing other unrelated queries to be pe

Re: Sealing or locking QuerySets -- a suggestion to prevent surprise N+1 queries.

1. I don't think the seal API on the QuerySet is enough, there are other ways implicit queries can be triggered without a QuerySet, e.g. Book(author_id=1).author . Shai's suggestion of using a query execution blocker is probably the best approach. If you were really worried you could even implement

Re: Sealing or locking QuerySets -- a suggestion to prevent surprise N+1 queries.

Hi all, Django 2.0 has a new feature[1] which allows you to say "I expect no actual database queries in this piece of code". It is not designed to stop a specific queryset from spawning requests, so getting it to do exactly what's asked for in this thread may be a little involved, but if your g

Re: Sealing or locking QuerySets -- a suggestion to prevent surprise N+1 queries.

I'm very interested in this feature and would love to assist in making it happen. On Thu, Jan 4, 2018 at 12:34 AM, charettes wrote: > Hey everyone, > > I also believe this is a feature that should be in core > judging by the number of times I had to enable query logging > in the past or rely on

Re: Sealing or locking QuerySets -- a suggestion to prevent surprise N+1 queries.

Hey everyone, I also believe this is a feature that should be in core judging by the number of times I had to enable query logging in the past or rely on assertNumQueries to make sure no extra queries would be inadvertently introduced in a critical code path. In the light of Anssi's comments on #

Re: Sealing or locking QuerySets -- a suggestion to prevent surprise N+1 queries.

1. I also could not find anything other than #26481 and a brief discussion of it on the list. 2. I've often wished for something like this, but ended up resorting to assertNumQueries() for lack of a better solution. So ye

Sealing or locking QuerySets -- a suggestion to prevent surprise N+1 queries.

At Zapier we're working with some rather complex and performance sensitive QuerySet building (most currently around experimenting with GraphQL) and I am constantly worried that the laziness of the ORM will surprise us in production (after a few levels of related nesting, the math of a mistake s