Thanks for your feedback. I appreciate it. 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.
Agreed though, I guess only a handful of apps encounter these problems. On Oct 4, 6:27 am, Russell Keith-Magee <freakboy3...@gmail.com> wrote: > On Sun, Oct 4, 2009 at 5:00 AM, James Bennett <ubernost...@gmail.com> wrote: > > > On Sat, Oct 3, 2009 at 1:58 PM, Thierry <thierryschellenb...@gmail.com> > > wrote: > >> I know this is not a problem for most users. But when working with > >> complex projects or projects requiring some performance optimization > >> django orm doesn't suffice. Its a pity to see strong development on > >> django orm, while at the same time the sqlalchemy project has huge > >> traction. I currently run both orm's. The gap between sqlalchemy and > >> django orm is very large. Are there any plans to integrate sql > >> alchemy? > > > In a word, no. > > To put in one more voice of authority - speaking as a core developer, > I'm strongly opposed to modifying Django to use SQLAlchemy (or any > other external project for that matter) as the ORM. > > On top of the many valid reasons that James mentioned, there is one > more that I consider to be very important - one that stems from the > task that _any_ ORM is trying to perform. > > The goal of any SQL-backed ORM is to provide a syntax that makes it > easy to express SQL queries. The problem is, we already have a very > powerful, 100% feature complete syntax for expressing SQL queries - > it's called SQL. By very definition, _every_ SQL-backed ORM is > reinventing the wheel. > > ORMs have an important role to play in making the simple cases very > simple - and this is a sweet spot that Django's ORM, SQLAlchemy, and > any number of other ORM projects manage quite well. It is much easier > to write "Author.objects.all()" than to write "SELECT id, firstname, > lastname, birthdate, address1, address2, .... FROM author". > > However, this argument isn't about the simple cases - it is about the > complex cases. I will certainly grant that SQLAlchemy is certainly > able to cover more of the world of possible SQL queries than Django's > ORM. However, there are queries that even SQLAlchemy can't express (or > can't express elegantly). At this point, you can either continue > making modifications to your non-SQL language in an attempt to provide > 100% coverage of the SQL spec, or you can step back and say "No - we > already have a language that does this", and embrace it. > > Django has decided to take the latter approach. The recent proposals > for a raw() operator to make it easier to return Django model objects > as the result of a raw SQL query is an expression of this underlying > philosophical direction. > > So, no - for this reason, and many many others, we're not going to > adopt SQLAlchemy as Django's ORM. > > That said, we are committed to making it easier to use non-Django > components inside a Django project. If there is anything that we can > do to make it easier to use SQLAlchemy (or any other non-Django ORM) > inside a Django project, we're open to those suggestions. > > Yours, > Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
