On 17 Jan., 05:36, Russell Keith-Magee <[email protected]> wrote: > On Sun, Jan 17, 2010 at 9:37 AM, Waldemar Kornewald > > <[email protected]> wrote: > > On Sat, Jan 16, 2010 at 10:35 PM, [email protected] <[email protected]> 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.
The current patch does not prevent any other backend, neither relationl nor non-relational ones, to be implemented. As Waldemar wrote we only added flags currently, such that each backend can decide itself if a set of features is supported or not. Databases like Riak and CouchDB which explicitly distinguish between insert and update can do it with the current modification too. In this sense the current patch should work for all non-relational databases and nothing is App Engine specific. > > >> 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. The main question of Waldemar was which proposal to follow (using QueryData or the current compiler approach introduced by mutli-db) and nobody answered! It seems that multi-db support made a good step towards even supporting non-relational databases. Such databases can use a compiler which can interpret SQL.Query. We thing that only minor modifications are needed to be completly SQL independent and to be abstract enough for non-relational databases. Following the QueryData proposal will most probably lead to copy 95% of SQL.Query. So we think that following the second approch is much better. But we need feedback! So we are asking for feedback in order to prevent ourself from following the wrong proposal. Again this is not the final patch and other changes will surely be added. Bye, Thomas Wanschik > 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 [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.
