On Fri, 2009-02-06 at 03:32 -0800, Waldemar Kornewald wrote: > Hi Russell, > > On 6 Feb., 11:34, Russell Keith-Magee <[email protected]> wrote: > > I would suggest to you that the broader project of "modifying the > > django.db.models interface to be fully independent of SQL" is much > > more likely to get core developer support. We (the Django core) will > > be very receptive to any suggestions on how django.db.models needs to > > be modified in order to support non-SQL backends -- especially if you > > can demonstrate that your suggestions aren't just theoretical, but are > > clearly required by an actual backend implementation. > > Agreed, making models SQL-independent is the most important (and most > complicated) part. Do the people secretly working on App Engine > integration try to implement that part?
I have a reasonably fleshed out plan to make things easier here in the Django 1.2 timeframe. The rough idea is that everything under django/db/models/sql/ could be replaced with a module of the developer's choosing (probably set via a setting). That package is the only place that really cares much about SQL. So somebody wanting a GAE backend or an Hadoop backend or something else would write something that behaved the same way as the Query class (and subclasses) and could be called by the QuerySet class appropriately. There are a few more details involved there than just that one setting, since it requires documenting the expectations (vs the currently convenient assumptions) that Queryset will make on the Query class -- probably that's pretty much what's there now, although I have a list somewhere of a couple/three things I wanted to look at. There's also simple enough stuff like removing the last vestiges of raw SQL from a couple of places (most notable related fields, but that should probably go after, or in tandem with, a rewrite of related fields to clean them up in general). There's also some thinking I have to do about where to draw the line for things like custom lookup types on fields -- how much do we encourage (with the noisy end of a cattle prod) people to be good extension-oriented citizens down the track and where can we help. We've tried pretty hard to keep the SQL-agnostic portions of the API separates from the database bits. I've made Russell's life a bit harder lately by asking for -- fairly insistently -- such changes in the aggregates patch to help with this goal going forwards, for example. The public API for querysets is fairly SQL agnostic, with the exception of Black Sheep extra(), and in that latter case, sometimes there's just nothing you can do about that. We take a fair bit of grief both here and in django-users for having this position, actually. Lots of requests for compromises to allow some half-breed combinations of raw SQL and querysets, which has hidden traps at both the design level and the extension level we're talking about here. So the changes you're talking about are certainly possible. 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
