Hi, > What's wrong with compound keys? SA has no problem with that. SA's > good at mapping all kinds of crazy stuff. I've even successfully > mapped a table with no viable primary key (at SA's SQL layer) and > then joined with another table to produce objects under SA's control.
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 - it's not even usable for referential integrity AFAIK. And creating these keys also becomes cumbersome, as it usually involves computing them somehow from provided data. > > - write you own model without any ORM at all, just using plain SQL > > and some > > magic, for example attribute access. > > This seems simple when you start down this path... eventually, you > just end up with a less-useful ORM. I'd either go completely with an > ORM or stick to SQL with access functions. Once you start making > things try to look like objects, you're just writing your own ORM. Certainly that was the least desireable option. And what I had in mind was more or less "only" sql with a thin layer for e.g. accessing a row as object with attribute names and type-mungering, but not relations. -- >> 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 -~----------~----~----~----~------~----~------~--~---
