On 1/27/06, hugo <[EMAIL PROTECTED]> wrote:

> >What happens to a query after it's been iterated?  For example, how
> >does the following behave?
>
> I'd say it  should memoize it's result - so it is only queried once per
> request to reduce database hits. But there should maybe a .reset()
> method on a manager to reset the memoized data, so you can rerun your
> query if you need to

Why not make the query object itself be the thing that is reset? e.g.

people = Reporter.objects.filter(fname="Joe")
for p in people:
     print p
people.reset()
people = people.filter(lname="Smith")
for p in people:
     print p

Would print all the reporters named Joe, reset the query, then rerun a
revised query to print all the reporters named Joe Smith.

Taking this approach a little further, it could also address Adrian's
Manager __call__ problem with Jacob's Article.objects() proposal.
Rather than exposing the manager itself, expose an interface that can
be used as a factory for producing Query objects. Keep the Manager
internally as a mechanism for managing database connections and SQL
composition, but don't expose it as the Article.objects member.

On the class itself, Article.objects(), Article.values(),
Article.in_bulk() become factory methods for producing Query objects
which, when iterated, provide objects of the expected type (instances,
dictionaries, etc).

filter, order_by, etc are kept as methods on a query object itself,
rather than methods on the manager. If you want to apply a filter, use
Article.objects().filter(headline="foo"). The metaphor here is 'make a
basic query object, then narrow it with a filter'.

On class instances, article_obj.sites() becomes the analogous factory
method for queries.

This approach also simplifies one use case for multiple managers -
pre-filtered Managers. If you need every query to have a particular
filter pre-applied, add a class method that returns
objects().filter(...) as required.

The one problem I can see is what to do with
article_obj.sites().clear(). I don't have a solution for this one,
other than to suggest making 'sites' an object that returns a query on
__call__. This is the same special case that Adrian objected to, but
it now only applies to modifying relationships in m2m queries, rather
than to every single class and query in the system.

Russ Magee %-)

Reply via email to