I updated the PR to do away with the public `clone()` method. As long as we have a long-term goal for a `QuerySet.clone()` method, I'm happy.
If we plan on changing the cloning behavior, now is effectively a bad time to introduce it. -- Loic On Jul 22, 2013, at 2:45 PM, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > 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 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. > For more options, visit https://groups.google.com/groups/opt_out. > > -- 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 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. For more options, visit https://groups.google.com/groups/opt_out.
