I find SQLObject very limited and it kind of makes me sad - I'm used to using Hibernate.
Small example: Why do property updates immediately execute UPDATE ?! What if we rollback the transaction? Wasted call. why not flush updates on commits? Right now I kind of feel like SQLObject is someone's pre-alpha technology preview. I'm looking to using TG for stats and reporting on an existing database, and I think I'm going to skip SQLObject. As for 'Think in Objects, think in tables' - The concepts are very similar, and I think one of the valuable assets anyone can have is to stand up to a significant amount of 'cognitive dissonance' - although I dont think the table/object "dichotomy" is all that severe of a difference. Serge Wroclawski wrote: > Everyone is different, but let me see if I can give you a few reasons why > objects make sense for me. > > First, using objects is more natural. I'm a Python programmer. SQL is > "something else". When I write Python, going to SQL requires a change in > mindset. It's a pain I'd like to avoid when I can. > > Secondly, for me, I like having the data validation in the object. We all > know that you can't rely on client side data validation, and while you can > be careful, putting the data validation low, near to the storage, makes it > easier. > > Third, SQLObject is database independant. I don't need to change (much of) > my code even if I change databases. This is a huge win if you prototype with > sqlite and move to mySQL. > > Fourth, I can use objects in clever ways, for example, to store data that's > not in the database in the object and make those distinctions invisible to > the application. > > That's why SQLObject is a win for me. > > - Serge Wroclawski
