I don't mean to be fresh, but why use an ORM at all? I'm finding that the learning curve for SQLObject is a bit steep. And then, when I really need to do something, which will nearly always involve joining multiple tables, I have to write a bunch of gibberish that really looks alot like SQL joins.
Sure, if I was in javaland, then I would be using hibernate and HQL to abstract away the db layer so that I could swap db implementations with just a config file change. But I'm not at all sure that you get that with SQLObject. So, if anyone cares to, please. Educate me as to why this is nec in the first place... As a related issue, any project of any size is going to want to abstract the database away and present a facade that will in turn talk to the db. The facade (or db wrapper, whatever) could use an ORM, or be jython talking to java + hibernate/jdbc, or use DB-API...etc. Meanwhile, I'm thinking of just using DB-API within TG to see if that is simpler or more confusing... -Todd
