On Sep 2, 2010, at 12:13 PM, Julien Cigar wrote:

> On 09/02/2010 17:55, Michael Bayer wrote:
>> On Sep 2, 2010, at 8:59 AM, Julien Cigar wrote:
>> 
>>> Hello,
>>> 
>>> Another quick question on .with_polymorhpic() .. :)
>>> 
>>> When I use inheritance I always subclass a Query object per mapped (child) 
>>> class, for example :
>>> 
>>> class QueryRoot(orm.Query):
>>> 
>>>  def available_to_all_children(self):
>>>    return self.filter(...)
>>> 
>>> class RootModel(object):
>>> 
>>>  query = Session.query_property(QueryRoot)
>>> 
>>> 
>>> class QueryChild(QueryRoot):
>>> 
>>>  def a_child_filter(self):
>>>    return self.filter(...)
>>> 
>>> class ChildModel(RootModel):
>>> 
>>>  query = Session.query_property(QueryChild)
>>> 
>>> 
>>> then the mappers:
>>> 
>>> mapper(Root, table_root,
>>>       polymorphic_on=table_root.c.type_id
>>> )
>>> 
>>> mapper(Child, table_child,
>>>       inherits=Root,
>>>       polymorphic_identity='child'
>>> )
>>> 
>>> it works well, and the ability of sub classing a Query class is very 
>>> elegant!
>>> 
>>> The only "problem" is that when I use something like :
>>> Root.query.with_polymorphic([Child]) I would like to be able to use 
>>> QueryChild filters (so be able to do something like 
>>> Root.query.with_polymorphic([Child]).a_child_filter()). Sounds logical 
>>> because Child columns will always be present in the result set (because of 
>>> the LEFT OUTER JOIN)
>>> 
>>> How would you do that properly?
>> RootQuery is already a subclass, override with_polymorphic to look at the 
>> args and produce the kind of Query class you want.
>> 
> 
> I'll do that :-)
> 
>>> Wouldn't it be interesting to add an option to .with_polymorphic()?
>> ummm this is all pretty Julien-specific stuff so far ... :)
>> 
>> 
> 
> hehe .. I hope I'm not thinking/doing something wrong :p

not at all.    The query is subclassable and you should tinker at will.   I 
just don't see a clear feature add for SQLAlchemy as of yet.   We try to be 
pretty conservative about adding new things and more often I'm trying to remove 
things that can be replaced with a more generalized approach.




> 
>>> Thanks,
>>> Julien
>>> 
>>> 
>>> -- 
>>> No trees were killed in the creation of this message.
>>> However, many electrons were terribly inconvenienced.
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "sqlalchemy" group.
>>> To post to this group, send email to sqlalch...@googlegroups.com.
>>> To unsubscribe from this group, send email to 
>>> sqlalchemy+unsubscr...@googlegroups.com.
>>> For more options, visit this group at 
>>> http://groups.google.com/group/sqlalchemy?hl=en.
>>> 
>>> <jcigar.vcf>
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy" group.
> To post to this group, send email to sqlalch...@googlegroups.com.
> To unsubscribe from this group, send email to 
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/sqlalchemy?hl=en.
> 
> <jcigar.vcf>

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Reply via email to