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
-~----------~----~----~----~------~----~------~--~---

Reply via email to