On 8/15/06, Jorge Godoy <[EMAIL PROTECTED]> wrote: > > "Tim Lesher" <[EMAIL PROTECTED]> writes: > > > It doesn't appear that there's a problem using just "id" for PK > > columns in SA (I'm doing it for my non-identity tables). Is there any > > reason not to make the two implementations consistent? > > IMHO it's a minor bug on the SA code. :-) They should be interchangeable in > an ideal world and since SQLObject came first and is the officially supported > ORM it is the reference.
Initially, they were compatible. You could switch one out for the other at any time if you hadn't made any modifications to the model. I used to agree with you that was better. However, after working with the SA model with integer id columns for some time, I think the current implementation is better. I'm even considering converting my project. The thing is that usernames are the ideal primary key for users, and since people often store references to users all around the database, it's just a pain to have to join to the tg_user table in every query. If you used the usernames as a primary key - you can infer the user from foreign keys since they store the username. Since using integer id's in this case is unnecessary in SA, it just looks wrong to do so for the sake of SO compatibility. I think the current implementation should be kept, with a recipe on the Wiki or in the docs on how to alter the SA model to make it compatible with the SO one. Arnar --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
