Todd Greenwood, el miércoles 26 de octubre a las 07:17 me escribiste: > > 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...
If you are (ab)using SQLBuilder, don't do that! This is not the SQLObject way: http://www.sqlobject.org/FAQ.html#how-can-i-do-a-left-join Try to think in objects, forget you are using SQL behind. -- LUCA - Leandro Lucarella - JID: luca(en)lugmen.org.ar - Debian GNU/Linux .------------------------------------------------------------------------, \ GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05 / '--------------------------------------------------------------------' VECINOS RESCATARON A CABALLITO ATROPELLADO -- Crónica TV
