Thanks, Jonathan and Simon.
With its seamless query support, association_proxy looks perfect for my
needs: it's just like having the extra fields on the master table, which is
where I'd put them ideally if not for some pathological technical issues.
I'm going to use it.
Thanks, D.
On
On Wed, Feb 11, 2015 at 4:10 PM, Jonathan Vanasco jonat...@findmeon.com wrote:
Simon,
why not use the association_proxy?
You just described this:
from sqlalchemy.ext.associationproxy import association_proxy
class Foo(Base):
_bar = relationship(Bar, uselist=False, lazy='joined')
qux =
Simon,
why not use the association_proxy?
You just described this:
from sqlalchemy.ext.associationproxy import association_proxy
class Foo(Base):
_bar = relationship(Bar, uselist=False, lazy='joined')
qux = association_proxy('_bar', 'qux')
--
You received this message because you are
Yeah, I use this use-case a lot.
I never actually search with it -- just usually map the scalar for display
needs.
But it appear to recognize the join and automaps if needed:
s.query(Foo).filter(Foo.qux == 'abc').first()
generates
SELECT foo.id AS foo_id, foo.id_bar AS foo_id_bar,
On Wed, Feb 11, 2015 at 1:47 AM, Dun Peal dunpea...@gmail.com wrote:
I have a declarative base called Foo, instances of which get most of their
attributes from a Foo SQL table. However, Foo also has a bar_id attribute,
which is a foreign key linking to the primary key of a Bar table. Bar is
I have a declarative base called Foo, instances of which get most of their
attributes from a Foo SQL table. However, Foo also has a bar_id attribute,
which is a foreign key linking to the primary key of a Bar table. Bar is
really just an extension of Foo, with a few extra attributes that belong
