On 1/25/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/25/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > If this were the case then it would be impossible to combine filter
> > and order_by, at least in this way:
> >
> > MyModel.objects.filter(creator__exact=5)
> > MyModel.objects.order_by('status')
> > for obj in MyModel.objects:
> > print obj
> >
> > For that code it seems like MyModel.objects should be a lazy
> > collection containing objects with creator=5 and ordered by status,
> > but in this case you would get an error because MyModel.objects
> > wouldn't support iteration.
>
> This is different than what I'd been envisioning -- I was under the
> impression MyModel.objects wouldn't contain state. A manager shouldn't
> contain state of the filter() queries that were passed to it. (This is
> a good argument for treating managers differently than many-to-one and
> many-to-many QueryResult objects.)
Why should field attributes contain filter state, and not managers
though? (Probably neither of them should BTW.) Allowing
filters/ordering on attributes seems like a really convenient thing,
but I think the semantics of attribute access are getting in the way
here. At any rate, having managers work one way, and "to-many"
attributes another is going to be confising to people.
Joseph
