MUST we explicitly supply the join to such query objects? Or is there
some way that SA can figure out that tbl_people_documents is in
between tbl_people and tbl_documents on its own? Perhaps there is
something we can add to the tbl_people/tbl_documents object
definitions that clues SA
Damon wrote:
MUST we explicitly supply the join to such query objects? Or is there
some way that SA can figure out that tbl_people_documents is in
between tbl_people and tbl_documents on its own? Perhaps there is
something we can add to the tbl_people/tbl_documents object
definitions
Thank you very much for the explanation. It is what I feared was the
case.
One of the great features we love about SA is the mappers, allowing us
to define table relationships in such a way that we can decide what
table(s) around which to pivot, giving us different ways of
returning data even
Damon wrote:
Thank you very much for the explanation. It is what I feared was the
case.
One of the great features we love about SA is the mappers, allowing us
to define table relationships in such a way that we can decide what
table(s) around which to pivot, giving us different ways of
you can explicitly create these many-to-many join relations and eager
load them.
users = session.query(User).options(eagerload(User.groups)).all()
if you want to query for relations with a filter, AFAIK you need to
define them as a separate relation.
class User(...)
groups =
Damon wrote:
MUST we explicitly supply the join to such query objects? Or is there
some way that SA can figure out that tbl_people_documents is in
between tbl_people and tbl_documents on its own? Perhaps there is
something we can add to the tbl_people/tbl_documents object
definitions that
