Hi, > 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).
Pretty much, most of the ORMs I used so far were in the Java-world. I'm sorry if I did SA injustice here. > > 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. Hm. You might be able able to create an extra index on (a,b). So referential integrity works. Sorry for the confusion. But this creates problems in the ORM I think. Lets say you have two objects of class foo: Table Foo=(a, b, c) X= Foo(1,2,3) Y=Foo(1,2,4) You can then create an index over a,b and refer to it by some other objects. Now this (a,b)-index creates a partition of all the objects Foo, grouping together e.g. X and Y. That it is where things become difficult - how do you ORM-map that? it would be a 1:n-relationship, that is shared by X and Y objects alike. Maybe SA allows for that - kudos to them then, yet I still believe that even if it does so, it won't be intuitive to do so. But maybe you prove me wrong here. And the point was not so much to say it doesn't work with an ORM at all- it was that reverse-engineering it from hand-written tables is not easily done, but requires lots of work. And sometimes the ORM doesn't fit the created relational model used so far so well, the above example was supposed to illustrate that. > > 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? Usually, number-based indices are generated using a sequence. Compound keys aren't. This makes creation of a new row more complicated - you have to know the key beforehand. The term "compute" wasn't chosen well, I admit. And I guess if you use compound keys, you will most probably know the values at creation time, making this a non-issue. I should have thought more about that, sorry. My initial reaction probably stemmed from seeing compound keys in live systems most probably always coinceded with a bad overall table design. -- >> Diez B. Roggisch >> Developer T +49 (30) 443 50 99 - 27 F +49 (30) 443 50 99 - 99 M +49 (179) 11 75 303 E [EMAIL PROTECTED] >> artnology GmbH A Milastraße 4 / D-10437 Berlin T +49 (30) 443 50 99 - 0 F +49 (30) 443 50 99 - 99 E [EMAIL PROTECTED] I http://www.artnology.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
