Hi, Es sprach Diez B. Roggisch: > Compound keys themselves might be manageable by a ORM-mapper. But I'v seen > them usually in places where for example a compound key made up from three > components (a,b,c) is used by a 1:n-relationship that only refers to two > of > these, e.g. (a,b). This doesn't go too well with ORM in my experience -
is this just a "it doesn't work with other ORMs, why should SQLAlchemy be different" conclusion or did you have real problems wiht SQLAlchemy? SQLAlchemy lets you join on arbitrary columns, I can't see why this should be different if the table description is loaded from the DB automatically (which I haven't used so far). > it's > not even usable for referential integrity AFAIK. I fail to see, why you shouldn't be able to have a primary or unique key on (a,b,c) and a foreign key to a different table on (a,b). Please explain. > And creating these keys also becomes cumbersome, as it usually involves > computing them somehow from provided data. This is where you lost me. Why should I have to compute anything? Cheers, --Jan Niklas --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears -~----------~----~----~----~------~----~------~--~---
