On Apr 29, 2007, at 1:10 PM, Eric Ongerth wrote:
> > Aha, I should have realized it was just the default cascade=save- > update. > > Thanks for the response; I went and read some more as recommended. > > So one strategy would be to just define physical_size as a method > inside of my Widget class, which goes and loads the physical_size of a > Widget instance from a widget_size_table. Was I correct in thinking > the strategy I mentioned already (mapping the property to a join) > should work? I would rather have the property mapped in, not > expressed as a class method, just so the syntax doesn't look different > for this property than for the other Widget properties. the usage syntax should be the same whether you use a relation() or a class-level property. the "does this make my mapper code look pretty" part of it i dont think should be a huge driving factor....you can always define your class-level properties separately from the class itself and place them along with your mapper defs, i.e. mapper(SomeClass, etc). SomeClass.accessor1 = property(lambda self: <somequery>) etc. this "how do i make relationships to wacky things using the relation () function" issue has been hot lately so maybe in a few weeks/months ill come up with some enhancements. > >> a relation like this cant be persisted > > Does that mean that I could not, for example, assign a physical_size > to a bunch of Widgets and expect the system to figure out what updates > should therefore be made in the widget_size_table? If so, that's OK > since that's the exact opposite of the information flow I'm looking > for. I suppose setting viewonly=True can be seen as a way of > informing SQLAlchemy of exactly that fact so that it doesn't have to > try and figure out the reverse. the primary design of a relation() is intended to support a single pattern: that of the primary table containing a direct foreign key relationship to the related table, with optionally a single association table used in between those two tables. you can also have extra join criterion between the primary and related table for the purpose of limiting the results of a select across those two tables, provided that those criterion dont provide any information about the relationship itself that the foreign key relationship doesnt already define. anything more complex than that, specifically any relationship that doesnt include the basic X->Y foreign key relationship, is not going to work on the INSERT/UPDATE/ DELETE side of things. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
