Joseph Kocherhans wrote: > On 1/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >>I'm not a fan of .all() either - if you can do .filter() on >>Article.objects, then surely Article.objects is already a collection of >>some kind. That's what is sounds like: Article.objects == all the >>'Article' objects. > > > And there's the original problem that started this mess ;-) Let me see > if I can lay it all out. (Sorry to pick on your response Luke, not > trying to single you out.) > > Case 1: > Let's assume that MyModel.objects or my_object.related_set *IS* a > Query object (in other words, it has state):
I have absolutely no idea how you arrived at this weirdo stateful model - it clearly makes absolutely no sense wrt concurrency. > Case 2: > Let's assume that MyModel.objects and my_object.related_set *RETURN* a > *NEW* Query object. (In other words is stateless.) You might expect > this: > > MyModel.objects # Q1 > MyModel.objects.filter(*args) # Q1 with filters applied > MyModel.objects.order_by(*args) # Q1 with ordering applied > > But in fact, you'll get this: > > MyModel.objects # Q1 > MyModel.objects.filter(*args) # Q2 > MyModel.objects.order_by(*args) # Q3 > > But this works fine: > > q = MyModel.objects # q is Q1 > q.filter(*args) # q is Q1 with filters applied > q.order_by(*args) # q is Q1 with ordering applied I really have no idea what you are talking about here. Sorry. The only interpretation I can make is that you are worried about making multiple database calls when you . The only alternative to this is to reimplement a relational database in python. Do you really want to do the filtering client side? Or what? I am having real trouble grasping your issue here.
