Re: object-relational mappers
Bruno Desthuilliers schrieb:
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
Bruno Desthuilliers schrieb:
Jarek Zgoda a écrit :
>
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.
>Bruno Desthuilliers napisa³(a):
>>
>>
>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.
>>
>>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.
>>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.
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
Comment