On Tue, 2009-08-11 at 07:55 +0800, Russell Keith-Magee wrote: > On Mon, Aug 10, 2009 at 10:56 PM, Alex Gaynor<alex.gay...@gmail.com> wrote: > > > > On Mon, Aug 10, 2009 at 7:19 AM, Waldemar Kornewald<wkornew...@gmail.com> > > wrote: > >> > >> Hi, > >> now that 1.1 is out we can finally discuss App Engine support. Is > >> anyone planning to work on this feature or working on it for real or > >> are there just announcements that someone might consider doing it? > >> > >> BTW, I've reworked the mini-spec a little bit to improve id/key_name > >> handling. Here's the link, as a reminder: > >> http://code.djangoproject.com/wiki/AppEngine > >> > >> Bye, > >> Waldemar Kornewald > >> > > >> > > > > As far as I know no one is working on this. Personally, I'm of the > > opinion that writing a basic backend (ie one that doesn't do JOIN > > emulation) shouldn't be an overly arduos task and is probably possible > > with no modifications to the existing Query class. Writing a more > > complete version (with JOIN emulation) may require some changes, > > however I very much doubt the exact nature of these changes will > > become apparent until someone actually starts to do the work. > > > > In conclusion, no on is currently working on, but for all the people > > who seem to ask for this I've seen almost no code written, which > > suprises me since this is something that can exist 100% external to > > Django (and probably should). > > I'm not completely convinced this is completely true with the current > codebase, but it's certainly 95% true. The ORM was designed to be SQL > agnostic, but there are a couple of places in where, in the name of > 'getting the job done', some shortcuts were taken that means that > Query assumes the presence of a SQL backend or SQL-like data > structures. The as_sql() call on Query is the one obvious example of > this, but there are some more subtle places where there is some > conceptual leakage.
Hmm... I would expect a backend to completely replace the Query class, not work around something like as_sql(). One part of making non-db backends supportable is to introduce a way to say "instead of using django.db.models.sql.*, use this other namespace for the Query class and everything it uses". That's why all the SQL stuff (modulo a few bits that haven't been done yet) is in the one namespace and the public API is entirely outside that namespace. A non-db backend ends up implementing at the QuerySet -> Query internal-API layer and that's where most of the tweaking will occur, I would imagine. The object structure for non-relational and other-storage-system backends is quite a bit different to the object structure required to create a relational-algebra-based tree (which is what Query does). [...] > My goal for supporting these backends at a project level is _not_ to > add them to the Django core - at least, not immediately, and certainly > not in the v1.2 timeframe. Instead, these projects _should_ be able to > be built and develop external to the Django core. In time, it may be > appropriate to add them to the core - but that is a long term goal, > not a short term goal. Definitely agreed. I think we know enough at this point to be able to provide fairly generic support for this kind of thing. We've been heading in that direction for a couple of years now, with that intent. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
