On 4/10/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
> hm, why is from_attr a classmethod ?
Because that way, you don't have to specify the related class at all,
and you can specify the parameters as args not kwargs. See my first
initial remark:
* I've implemented Query.from_attr, instead of adding new keywords to
the Query "constructor", because I think:
Query.from_attr(someuser, 'addresses')
looks better, is shorter and is more readable than:
Query('Address', instance=someuser, attr_name='addresses')
> not very consistent with all the other generative methods ?
True, but I think it makes more sense this way (see below).
> can we have a regular generative method as well ?
If you really want one, I'll gladly do it, but I don't think it makes
sense because that method can possibly change the mapper.
So, first I'd need to duplicate part of what is in the __init__
method, which doesn't feel right.
And second, I think it could be quite confusing for a user. Imagine
that Query(A).from_attr(inst, 'rel') could return instances of B (or
whatever class is attached to the relation)... Probably not what you'd
expect. So, if we go down that route, it would probably be a good idea
to check that the mapper in the cloned query is the same than the one
we get from the relation.
And by the way, from_attr doesn't sound like a generative method, so
if you want it, what about "filter_from_attr", or something similar?
--
Gaëtan de Menten
http://openhex.org
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
