Re: [Sqlalchemy-tickets] [sqlalchemy] #2743: Backref broken for detached objects

[sqlalchemy <mi...@zz...>]

#2743: Backref broken for detached objects
-----------------------------------+------------------------------------
      Reporter:  schlamar          |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  medium            |  Milestone:
     Component:  orm               |   Severity:  no triage selected yet
    Resolution:  worksforme        |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+------------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * resolution:   => worksforme
 * status_field:  awaiting triage => completed/closed


Comment:

 This behavior is by design.   Implicitly populating the reverse side of a
 collection would add significant overhead to the object loading process,
 when it has not been requested (and you can request it, see below).
 Additionally, reverse-side collection population is not even feasible when
 the relationship is a many-to-many - if you had a many to many between
 A<->B, and you were to load a subset of A "ASub", which then loads the
 list of B objects "BASub", those B objects may refer to many more "A"
 objects outside of "ASub" and you'd see a lot more rows being loaded than
 were requested.

 In this case, the situation between eager loading the one-to-many also
 resolving the many-to-one can be achieved most efficiently using the
 `immediateload()` directive, since these many-to-ones can all be pulled
 from the identity map with no additional SQL:

 {{{
 #!python
     parents = session.query(Parent).options(joinedload('children'),
 immediateload("children.parent")).all()
     session.expunge_all()
     print parents
     print parents[0].children
     print parents[0].children[0].parent
 }}}

 Note that SQLAlchemy orients itself towards the "attached" object use
 case; detachment's primary use case is that of transferring or caching
 objects to be reattached to another `Session` for subsequent usage.  While
 working with objects in an explicitly detached state is supported to some
 degree, it will always have caveats.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2743#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python