You don't need to use SQLObject at all. This is not a requirement of TurboGears. Just that you saw the sample which involves data storage chose SQLObject.
I found SQLObject to be very versatile though as it removes all the interfaces issues with a database(data type mapping, multiple database backend has slightly different syntax etc.) But if you need things beyond simple two tables(either one to many or many to many) manipulation, you need RAW SQL. Just use stored procedure for this kind of thing as anything too complex should not be done at the client anyway, unless you can stuck them all into one single SQL statement of course. Todd Greenwood wrote: > 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
