On Jan 9, 2012, at 11:19 AM, Michael Bayer wrote:
> The first thing I note here is, if I were doing a model like this, I'd either
> use two different association tables between Product->Origin and
> Product->Food, or I'd make one relationship(), and handle the filtering in
> Python (which is essentially what you're wishing SQLAlchemy did here). The
> ORM wants to know about your table relationships which here is just
> A->assoc->B. All of the issues here, some of which I consider to be SQLA
> bugs anyway, would go away if you did it in that manner, subqueryloading
> would be efficient, etc.
Here's an event that does what you need:
from sqlalchemy.orm import attributes
from sqlalchemy import event
class Product(Base):
__tablename__ = "product"
id = Column(Integer, autoincrement=True, primary_key=True)
options = relationship(SearchOption, secondary=product_searchoption_table)
origin = relationship(OriginOption, uselist=False,
secondary=product_searchoption_table)
foods = relationship(FoodOption,
secondary=product_searchoption_table)
@event.listens_for(Product, "load")
def mything(target, context):
if 'options' in target.__dict__:
attributes.set_committed_value(
target, 'foods',
[o for o in target.options if o.discriminator=='food']
)
origin = [o for o in target.options if o.discriminator=='origin']
attributes.set_committed_value(
target, 'origin',
origin[0] if origin else None
)
# only 2 queries
for row in session.query(Product).options(subqueryload(Product.options)):
print row, row.origin, row.foods
if I added an onload event for individual relationship attributes that would
make this event a little more targeted.
--
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
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
