On Sunday, July 21, 2013 9:53:36 PM UTC+3, Loic Bistuer wrote: > > Explicit is better than implicit and `all()` is more a `Manager` concept > than a `QuerySet` one. > > IMO `QuerySet.all()` should only be used when API parity with `Manager` is > needed. > > Internally `QuerySet` uses `_clone()` rather than `all()` and with #20625 > on its way, I think it's useful to have a public `clone()` method. > > The biggest problem with public .clone() method is that the private ._clone() doesn't do just cloning. There are some cases where cloning also changes how the QuerySet behaves. For example using QuerySet.query.add_q() multiple times could behave differently depending on if there is a .clone() operation in between. IIRC there are some other cases which behave differently when chaining multiple operations. Of course, the same problem is there when using .all() for cloning, too. Still, I don't think it is a good idea to have public .clone() API if it does more than a pure clone.
Splitting ._clone() to two parts has been on my wishlist for a long time. The first part would be pure cloning, the second could be .next_operation() or something like that which does the needed changes to support queryset chaining behaviour. Another benefit of doing this cleanup is that it would be fairly straightforward to implement "in-place" querysets which would make certain ORM operations cheaper. So, for the time being having .all() as clone API seems good enough to me. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
