Re: ORM roadmap
On Sun, Oct 4, 2009 at 5:00 AM, James Bennett wrote: > > On Sat, Oct 3, 2009 at 1:58 PM, Thierry 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 -~--~~~~--~~--~--~---
Re: ORM roadmap
On Sat, Oct 3, 2009 at 1:58 PM, Thierry 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. There are several reasons, some quite independent of each other, for Django having its own ORM and trusting that people who don't like it or want/need something else will take advantage of the fact that Django's just Python, and will use whatever ORM solution they prefer. First, and dearest to my heart as release manager, is simply that a move toward SQLAlchemy would be large enough and disruptive enough that we couldn't in good faith do it during the Django 1.x release series; if it were to happen at all, it'd have to happen at a bump of the major version number (e.g., in a move from a Django 1.x -> Django 2.x). You'll notice, for example, that even something as tiny as switching ``AdminSite.root`` to an include of ``AdminSite.urls`` is going to need multiple full release cycles to complete, because we have a strong commitment to API compatibilty and stability, and so follow the same general process as Python itself for deprecating and removing pieces of API. Given what's involved even in a tiny change like the admin URLs, it should be fairly clear that we simply could not switch ORMs midstream in a release series even if we wanted to. Second, I don't particularly think there's a major need to try to make everyone converge on one single ORM, or even as large a community impetus as you may suspect; there are, right now, either four or five (depending on how you want to count) major Python ORM projects with decent community support, and none of the others seem to be particularly interested in abandoning their efforts (or even feeling any particular pressure to do so) in favor of a merge with SQLAlchemy. Third, and somewhat related to the above, I don't think it would be a good thing for Django to do this; SQLAlchemy is a very good ORM, certainly, but it also has a certain approach to and assumptions about ORM which are very deeply and very rigidly embedded into it. It is, fundamentally, a Data Mapper-style ORM, and that will practically always be visible and have effects on end user code even with extensions designed to emphasize a different approach. Django's ORM, meanwhile, has its own approach and assumptions which are, again, rather deeply and solidly built in; it is, fundamentally, an Active Record-style ORM, and that will practically always be visible and have effects on end-user code. And this is not a bad thing! Both of these are valid, respectable approaches to the ORM problem, and personally I think the Python ecosystem would be poorer, not richer, if one of these approaches were to be eliminated. Right now Django and SA represent the "best of breed" implementations of these approaches, and in order to keep good implementations available I think the Django ORM needs to continue to be developed and supported. Fourth, it's worth noting that we have certain stated goals for what we'd like our ORM to do, and those goals are irreconcilably incompatible with stated goals of SQLAlchemy. For example, it is a goal of Django's DB layer to eventually support backends which are not SQL databases (e.g., the BigTable implementation in Google App Engine, CouchDB, etc.). So far as I know, however, SQLAlchemy has stated unequivocally that they will remain SQL-only. I could probably go on for a while here, but hopefully it's clear by now that there are some fairly solid arguments for Django continuing to maintain and use its own ORM solution instead of switching to SQLAlchemy (or any other project which might come along and gain similar traction -- it's useful to remember that, in the beginning, emails such as yours asked why we didn't just switch to SQLObject, since that was at the time the standard default ORM in other major frameworks; had we done so we'd have been in a bit of a pickle when everybody abandoned it). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: ORM roadmap
On Sat, Oct 3, 2009 at 2:58 PM, Thierry wrote: > > http://code.djangoproject.com/wiki/Version1.2Features > > 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? > > > > No. There are no such plans, we wouldn't be doing development of our own ORM if we planned to throw it away. There have been external projects to integrate SQL Alchemy into Django, but I hvae no idea what the status of them is. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ORM roadmap
http://code.djangoproject.com/wiki/Version1.2Features 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? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Revisiting #8245: admin.py errors under runserver cause app to disappear
I haven't looked hard at the fix, but I hit the bug a lot and agree that it would be great if this was fixed :) On Oct 4, 3:12 am, Carl Meyer wrote: > Anyone have thoughts on this? It would be really nice to get this > fixed so admin.py errors don't break the runserver, and I think the > updated patch on #11957 accomplishes this without any breakage. > > Carl > > On Sep 28, 4:56 pm, Carl Meyer wrote: > > > > > Today I filed #11957 [1], and because it is questioning an earlier > > bugfix, I was asked to bring up the issue for discussion here. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Revisiting #8245: admin.py errors under runserver cause app to disappear
Anyone have thoughts on this? It would be really nice to get this fixed so admin.py errors don't break the runserver, and I think the updated patch on #11957 accomplishes this without any breakage. Carl On Sep 28, 4:56 pm, Carl Meyer wrote: > Today I filed #11957 [1], and because it is questioning an earlier > bugfix, I was asked to bring up the issue for discussion here. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---