>>>and how do you reset it? >> >>I think this is a legitimate need, and one that can be simply supported >>with a clear_cache() method on QuerySet or whatever.
> The problem is I've been thinking of Article.objects() where the > return value is an object representing an instance of a _query_, which > can be modified, executed, reset, cached, or whatever. You, on the > other hand, are looking at Article.objects being as a higher order > representation of the underlying _set_. This does accurately summarise the original idea, yes. I really don't see why people want to make .objects callable. It just seems to be worse in pretty much every situation. > In your context, I'll agree that what I've been proposing doesn't make > much sense, because there _is_ only one higher order representation of > the underlying data. If you need to filter, you have a different set. > Your version doesn't need Article.objects.all(), because > Article.objects _is_ all. The only problem here is concurrency, which, > as you rightly pointed out, is pretty close to a non-issue. > > From my context, Article.objects() constructs a basic query that knows > how to return all object instances of type Article, which can then be > filtered to produce more complex query objects. The idea that there is > a single basic query which everyone should use doesn't really make > much sense - each query you want to make is unique, so it should have > its own cache/state/etc The only ones which will be shared are the ones which are the same object... which necessarily implies that the query/result set will be the same. The query specification in any particular "QuerySet" is immutable. The cache is just an optimisation. Make sense? > Half the confusion lies in the fact that my approach _could_ use your > syntax, and vice versa, but on both counts, it wouldn't make much > sense to do so, because of the way each solution represents the > underlying problem. > > The rest of the confusion (at least on my part) stems is that there > are a lot of references in this thread and the wiki to Article.objects > being the Manager, with all()/filter() etc being used to get sets from > the Manager; as a result, my mental picture of the Manager isn't one > of a higher order set, it is one of managing SQL composition and a > connection to a database. If you need to call objects.all(), then > 'objects' by itself doesn't really represent anything other than a > namespace for functionality. > > Does this sound like I have a better understanding of your position > now? Does it clarify mine at all (not that you necessarily agree, but > at least see where I'm coming from)? The whole point of the descriptor fields proposal was to make django orm code look a lot more like standard python code, rather than java code ( getter methods abounding). I have no idea where the .all() thing came from, and have always argued against it... to me, this seems like having to do [1,2,3].all() to construct a list - it puts up an artificial barrier between the collection and its contents. I've got no idea why people want to do that - I'm assuming it is because they are hung up on the idea of knowing exactly when database calls happen or something. Sorry if I've been abrasive, its a mixture of annoyance at not having the time to do this myself, and seeing the same arguments as happened on IRC and this list a while ago repeated. This is really my fault for not implementing it all earlier ;-( Anyway, thanks to anyone who is going to implement this stuff, it should make django programming a lot more natural imo.
