On Sun, Jan 17, 2010 at 9:37 AM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > On Sat, Jan 16, 2010 at 10:35 PM, flo...@gmail.com <flo...@gmail.com> wrote: >> I'm not really a developer on Django itself, but I am fairly >> interested in non-relational databases, and some of the things being >> said in this thread worry me a bit. > > OK, if you read my mail literally I sound like "all" nonrel DBs are > the same. Of course they're not and you can find a counter-example for > almost everything. There's nothing to worry about, though. The > counter-examples simply need additional changes to get supported. It's > not like my changes would prevent other backends.
No, but they don't allow other backends either. From my perspective, the purpose of this effort is to make the modifications to core that make *any* backend that stores data possible. >> I think these efforts are great--a lot of people want to get up and >> running on GAE with Django, and it's not so easy right now. It just >> worries me a bit that the description of the effort encompasses all of >> non-relational databases when the implementation seems to primarily >> reason around GAE. It makes sense to concretely pick one database and >> start there, otherwise no work would ever be finished, but I think >> that the better thing to do is to call it GAE support instead of >> nonrel support. > > We have people interested in adding MongoDB, CouchDB, and maybe > SimpleDB support. The current code should be abstract enough for > SimpleDB and probably also MongoDB (though, it would help to modify > AutoField to also support string values). Other DBs might need > additional changes, but that's what the "nonrel" project is for. > Everyone can join and work on Django changes needed for their DB. We need to be clear about your goals here. Speaking for me personally, It's going to be very hard to get me to be interested in this project unless you're trying to solve the whole problem. We have a backend interface that works well for SQL. I'm interested in seeing the set of modifications that are required in break the SQL-specific aspects of that interface. I'm not at all interested in spending a bunch of time vetting modifications that only solve part of the problem - especially when those modifications may well prevent the elegant introduction of a fully refactored backend interface. I have no problems with the idea of tackling this problem in an iterative fashion (i.e., get it working for GAE, then get it working for GAE+MongoDB, and so on), but I'm not going to commit anything to trunk until you've got enough backends (with enough breadth of features) to demonstrate that the refactoring that you propose is sufficient to solve the general problem. 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-develop...@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.
