Russell Keith-Magee wrote:
On 2/14/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
This change, at a glance, looks good. Go ahead and commit it.
Ok. Will do.
cached vs. non-cached query sets. The way it's currently handled in
magic-removal is great, and a fine improvement. Let's move forward.
If this is the will of the gods, it shall be done. However, some of those
decisions were made in the abstract. Now that we have code to look at, some
problems/alternatives have bubbled to the surface.
If you go back to the original thread in which all() was decided upon (in
particular, the post where you "finally wraps his brain around the
problem"):
http://groups.google.com/group/django-developers/browse_thread/thread/f64127c9b63e2ae5/3362cb72dc6641cf
I believe we have sorted out the issues that were raised in that thread that
lead to the all() decision:
1) if Article.objects is cache disabled there is no persistence problem
2) Article.objects.cached() provides easy access to caching if optimization
is required
3) list(Article.objects) is possible, but certainly not required
4) In the some_view() example used in the thread, the decision to use
caching can be kept out of the template.
5) All the proxies of get_pub_date_list that you wanted to avoid already
have been - using QuerySet descendents like DateQuerySet
6) All of the proxies that the all() solution requires can be removed
I know there is little point in continuously revisiting old decisions, but
this is a big decision that we will have to live with for a long time, so it
seems important to make sure we have it right.
Russ Magee %-)
I agree with this 100%... ( it can happen !)
