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 -- http://mail.python.org/mailman/listinfo/python-list
