Hi, Diez B. Roggisch wrote: >> is this just a "it doesn't work with other ORMs, why should >> SQLAlchemy be different" conclusion or did you have real problems [...] > > Pretty much, most of the ORMs I used so far were in the Java-world. > I'm sorry if I did SA injustice here.
OK. What I like about SA is that it is so much more flexible than any other ORM. >> 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. Ok, now (having read the following as well) I understand, that you want to refer from B:(a,b,...) to A:(a,b,c,...) and want to be sure that there is at least one (a,b,?,...) in A for each B. But in the end, we're talking about n:m (an A might refer to any Number of Bs, but a might be referred by any number of As). That's OK, but AFAIK under these circumstances you're right about simple foreign key constraints: they won't work here. You'll have to use check constraints. *But*: This is a problem on the DB side, so what, as long as the ORM can handle it... > 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. In SQLAlchemy you dont need the index to refer to all (1,2,?). > 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? You have an iterable for all these Objects. > 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. Try it, I can't say if you think it is intuitive. The bottom line is this: SQL has two layers: One models the DB, one models the logical structure. The data element in the logical structure are properties that change the state in the "DB objects". This helps SA to work around the problems that you mention - it's not as simple as other ORMs, but this means: You can do more, but you have to learn more as well. > 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. AFAIK these proplems are just what SQLAlchemy is for. >> 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. OK. Now I understand what you meant. > 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. I know what you mean, but I don't like "every table needs an ID" design either. 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 -~----------~----~----~----~------~----~------~--~---
