object-relational mappers

[Diez B. Roggisch]

Bruno Desthuilliers schrieb:
> Jarek Zgoda a écrit :
>> Bruno Desthuilliers napisał(a):
>>
>>> Now my own experience is that whenever I tried this approach for
>>> anything non-trivial, I ended up building an "ad-hoc,
>>> informally-specified bug-ridden slow implementation of half of "
>>> SQLAlchemy. Which BTW is not strictly an ORM, but primarily an attempt
>>> at a better integration of SQL into Python. So while it may feel like
>>> learning the inner complexities of SQLALchemy (or Django's ORM which is
>>> not that bad either) is "wasting brain cells", MVHO is that it's worth
>>> the time spent. But YMMV of course - IOW, do what works best for you.
>>
>> I like OR mappers, they save me lot of work. The problem is, all of them
>> are very resource hungry, processing resultset of 300k objects one by
>> one can effectively kill most of commodity systems. This is where raw
>> SQL comes in handy.
> 
> The problem here is not about how you build your query but about how you 
> retrieve your data. FWIW, SQLAlchemy provides quite a lot of "lower 
> level" SQL/Python integration that doesn't require the "object mapping" 
> part. "raw SQL" is fine, until you have to dynamically build complex 
> queries from user inputs and whatnot. This is where the "low-level" (ie: 
> non-ORM) part of SQLAlchemy shines IMHO.

The same can be said for SQLObjects SQLBuilder. Even if I ended up 
generating SQL for some query that didn't touch the ORM-layer, it helps 
tremendously to write e.g subqueries and such using python-objects 
instead of manipulating strings. They help keeping track of already 
referenced tables, spit out properly escaped syntax and so forth.

Diez