On Jan 19, 2009, at 5:32 PM, Jon wrote:
> > The recent upgrade to 0.5.0 (again, thank you) from 0.5.0rc4 brought > with it a new message regarding many-to-many relationships and > cascades (specifically, delete cascades). > > I have a few questions - one is general and the other has to do with a > more specific problem. > > First, the general question: > > Since delete cascades will not be supported on many-to-many > relationships in 0.6 (why not?), is there a way to resolve this issue? because it doesnt really work in any version of SQLAlchemy. in your case you have a 1:1 so it "works", but in a true manytomany situation, SQLA does not load up all the potential parents of the object to check for an "orphan". the original meaning of "orphan" implies an object that can only have one parent. usually when people put the orphan thing on m2m they expect it to detect that no parents remain, which is not what it does. > The more specific question deals with a database I have inherited. I > have some tables which have a *logical* relationship of 1:1 (ie, the > actual usage is 1:1) but due to legacy issues the actual data > definition in the database is described as a many-to-many due to the > presence of a join table (aka "secondary"). What is the best way to > represent this in SQLAlchemy without changing the database structure? > Bonus points for working cascades. In other words, I have three > tables: A, B, and C where A and C should have a 1:1 relationship (C > would have a foreign key ref on A's primary key and so on) but instead > B is used as a join table. we haven't decided in 0.6 how to approach this yet. perhaps we can lift the warning if the child object has "uselist=False" on its parent relation, or add a flag such as "single_parent=True", something like that, since technically we should be doing something similar for manytoone as well. I'd want to put some kind of in-python "you just tried to add a second parent for X" type of logic that expressly prohibits creating a second parent for such a relation. I wouldn't change what you're doing just yet, or you could do an association pattern by mapping B explicitly. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---