Thanks for the explanation Mike! Seeing it now, I actually think there’s a decent reason to want the current backerefs:
My understanding is that with session.merge in SQL Alchemy it’s possible to draw a very clean line between entities that are persisted (or about to be persisted on the next flush) and entities which will never be persisted. This is owing to the design choice whereby SQL Alchemy doesn’t persist the entity you pass into the merge; instead, that is kept alone and a new entity is created. With this in mind, there are two ways to see Lyla’s example. One way: as soon as the tassel_thread was related to the persisted my_head (persisted because of the line my_head=session.merge(my_head)) then tassel_thread should be seen as in the session already. In this view, the merge is necessary and possibly error-prone, as here. Another way: instead of assigning my_head=session.merge(my_head), keep the unpersisted head around with say persisted_head = session.merge(my_head). Then relating the new tassel_thread to my_head won’t add it to the session. To get a record into the DB, then do a session.merge on it - everything works correctly this way. In both cases, there is the idea of a persisted object graph and a distinct unpersisted object graph. Once you relate a new entity to something in the persisted object graph, it becomes persistent. -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
