I guess it depends how you look at it. To me assign_mapper adds some
Query methods and not others; e.g., .select and .count but not .filter
. I assume that's because .filter is so new. But in the manual under
"Generative Query Methods" it implies that .select and .filter are
parallel; i.e., you can use either one depending on whether you want
the results now or you want to modify the query further. With the
regular mapper it's easy to switch between the two by merely changing
one method name:
rslts = ctx.current.query(MyClass).select(...)
q = ctx.current.query(MyClass).filter(...)
But with assign_mapper they are not parallel and you have to add or
delete an otherwise-useless .query() call (useless because it takes no
arguments):
rslts = MyClass.select(...)
q = MyClass.query().filter(...)
As the application's needs change, users will frequently have reason
to switch between .select style and .filter style.n You've mentioned
earlier that you're not fond of Query.select() at all because users
confuse it with Table.select(), and recommended .filter(...).list()
instead. If people start doing this wholesale there will be a lot of
transformations from .select to .filter, and this same issue will come
up.
At the same time, I share your concern about adding too many methods
to the user class, especially since they may someday collide with one
of my database columns. I would rather have parallel select/filter
than lots of user class methods. I suppose I could just pretend
.select() and .count() don't exist, and use .query().select() and
.query().filter() and .query().count() instead -- if .query() is going
to be documented and supported long term.
I can see why it would be a pity to lose .get(). But on the other
hand, why should some Query methods be privileged and others not?
--Mike
On 5/31/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
> heres the question. Query gets 10 new methods one day. do we then
> add 10 methods to assign_mapper() ? must the user class be a total
> clone of Query ? assign_mapper just bugs me for this reason. hence
> i like entity.query() better. im not sure which one youre saying you
> prefer ?
>
> On May 31, 5:46 pm, "Mike Orr" <[EMAIL PROTECTED]> wrote:
> > What are future plans for the assign_mapper query methods?
> >
> > MyClass.select(...)
> > -- works great. A clear advantage for assign_mapper over the
> > regular mapper.
> >
> > MyClass.filter(...)
> > -- doesn't exist.
> >
> > MyClass.query().filter(...)
> > -- works but is undocumented and requires a convoluted monkeypatch
> > in the source. Not so clear an advantage over the regular mapper
> > because it's so verbose.
> >
> > The third is the one I've found most useful. That way I can have
> > functions that return a Query, and the caller can call .select(),
> > .select(offset=,limit=), or .count() as they wish.
> >
> > --
> > Mike Orr <[EMAIL PROTECTED]>
>
>
> >
>
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
