> I find an orm usefull for 3 scenarios: > 1. - simple object retrieval posts.objects.all() > 2. - performance optimized object retrieval, your raw approach would > suffice here > 3. - generating complex queries, and reusing sql components > When you get to complex data models, Django currently fails on 2 and > 3.
I'd agree and elaborate on #1, that ORMs are good for simple object retrieval, and also for eliminating some of the most grievous cross-platform issues. However, I must disagree on #2 and #3: I'd never consider the *addition* of a generalization-layer (an ORM in this case, but the idea is far more broadly applicable) a step towards optimization. Likewise, for my more complex queries, there's no good way to express them efficiently in *any* ORM I've used -- many end up either inexpressible, or they involve bringing back gobs of data client-side and post-processing it there instead of at the server. I use an ORM for the same reason I use Python: they make common tasks easy. Using Python/ORM, I can bang out most of what I need. But when I hit a wall (performance or complexity), both need to allow be to go *down* a layer (to C or SQL). So I'd say Django has done a fine job of making the ORM what it should be -- an approachable, cross-platform, cross-database data-access layer that covers most use-cases and gets out of your way when you need it to. -tkc --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
