If I can comment on what seems instinctive to someone who just recently read the documentation, and made assumptions based off of it: My understanding was that the relationship abstractions were supposed to be about making foreign keys easier to keep track of, and being able to go both ways on a relationship in a object-oriented way. The fact that there were any implications at all for persistence was surprising to me, and it took me a significant amount of time to understand that SQL Alchemy was trying to do some magic behind the scenes when it came to persistence. I support the idea of making cascade_backrefs=False by default, because it keeps the separate objects separate, it makes me less nervous about eventual performance (which is a constant concern when there is magic I didn't intend happening in a library), and it's basically just working the way that I expected things to work initially. I'm fine with dealing with errors that might come about from the implications of updating of objects independently. It seems like part of the responsibilities of dealing with persistence, ever.
</my two cents> -Lyla On Sun, Apr 28, 2019 at 10:54 PM James Fennell <jamespfenn...@gmail.com> wrote: > 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 a topic in the > Google Groups "sqlalchemy" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sqlalchemy/oVVdbCzsNQg/unsubscribe. > To unsubscribe from this group and all its topics, 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. > -- 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.
