From: Nick <ni...@dd...> - 2003-04-30 21:11:45
|
On Wed, 2003-04-30 at 15:25, Luke Opperman wrote: > Is there a reason you can't add an artificial surrogate key? Because it's sloppy :) I prefer to fix the tool to fit the practice rather than change a perfectly good practice to fit the tool. In my case I've got a permissions table that maps groups and files to permissions. It would be very messy to create intermediate tables just so SQLObject can do RelatedJoins. On Wed, 2003-04-30 at 15:46, Ian Bicking wrote: > I would subclass RelatedJoin, changing the performJoin method. In > general I think any table that doesn't have a key should be represented > with a join, and rows in that table won't be turned into full objects. > That means they won't be mutable, but it shouldn't be a problem to just > add and delete rows instead of changing them. Yes, that's pretty much how I did it with my old framework. However, this can create a *lot* of write queries if you're changing a bunch of different columns. Which goes back to the whole transaction discussion. Nick |