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.


Reply via email to