I find SQLObject serves its purpose pretty good, though I would say that for my app, 70%+ of it would not be using SQLObject because I need SQL, not object for the core business logics.
My impression about the "think in Object vs think in table" is more towards "imperative vs declarative" and I don't think they are similar. But I find the need for using both. As for the update, I believe there is some way to defer it. dj_ryan wrote: > 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
