Evan James <thas...@gmail.com> wrote:
> Hi folks, > > I'm working on a SQLAlchemy-based app where we've decided to make some > infrastructure changes, in particular moving from reflection to declaration > for mapping the models. > > However, we're now running into issues where, after switching to declarative, > relationships aren't populated the way we expect when manipulated in Python. > For example, we have code that looks like this: > > class Widget(...): > def merge(self, other_widget): > """Merge the widgets, transferring the dependent items on the other > widget to this one.""" > for frobnicator in other_widget.frobnicators[:]: > frobnicator.widget = self > > meta.Session.delete(other_widget) > > > This code worked as hoped-for when we were reflecting on the database to > create our mappers, but after switching to declarative, the dependent items > are cascade-deleted on commit when other_widget is deleted, rather than being > preserved as children of the merged widget. > > It's not difficult to fix this particular issue - explicitly removing the > frobnicators from the other_widget.frobnicators collection will prevent them > from being deleted, and then the merged widget correctly has them - but we're > finding we have a class of bugs where relationships aren't being handled the > same way as before. Unfortunately, "build a comprehensive test suite" is one > of the infrastructure changes we're in the process of making - which means > it's not done yet and we can't easily track down all the places we could get > tripped up. We would really prefer to resolve this by changing the > definitions in the models, not by changing the application code that > manipulates the membership of relationships. Essentially the issue is likely because the mappings in these two examples are not equivalent; the reflection based version has Widget.frobnicator and Frobnicator.widget communicating with each other through a backref, and the declarative version does not. Assuming you’re on SQLA 0.9, the reflective version is taking advantage of the behavior introduced in http://docs.sqlalchemy.org/en/rel_0_9/changelog/migration_09.html#backref-handlers-can-now-propagate-more-than-one-level-deep; that is, adding frobnicator to first_widget.frobincators affects the backref of frobnicator.widget which then automatically performs the remove of second_widget.frobnicators. The declarative version does not make any use of the “backref” or “back_populates” keyword so cannot take advantage of this behavior; it doesn’t track any linkage between these two sides. The section http://docs.sqlalchemy.org/en/rel_0_9/orm/backref.html?highlight=backref talks about how to configure either backref or back_populates between mutually-dependent relationships. > I've created a reduced test case here which specifically displays the > behavior we're having trouble with in minimal form. If one line in the test > case is commented out, the test will pass for reflective models and fail for > declarative models; if the line is put back in, success and failure reverse. > > My question: How can we make relationships function identically in > declarative syntax as they did in reflective syntax? We thought we had > migrated mapping styles in a way that wouldn't change anything, but here we > are. What are we missing? > > Thanks, > Evan James > > -- > 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 http://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. -- 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 http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
