On Sun, Jan 17, 2010 at 9:56 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > On Sun, Jan 17, 2010 at 5:36 AM, Russell Keith-Magee > <freakboy3...@gmail.com> wrote: >> 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. > > It is, absolutely. I think most (if not all) of the other key-value > stores need just two additions: > > 1. AutoField with string values > > 2. Extra backend-specific meta-data in Model > CouchDB and other versioned backends would store the internal revision > number and use that on UPDATE, for example. > > In my previous mail I already mentioned that probably all nonrel > backends will need to know the pk column names of all tables in order > to emulate JOINs and maybe a few other features. > > Have I missed anything?
Yes :-) Like I've said several times now, I'm not focussing on non-SQL backends at the moment. I can give you broad guidance as to the type of proposal that we are likely to accept. My last email was an attempt at such advice (i.e, your proposal shouldn't be GAE specific). I can also give you specific advice on specific questions about Django's architecture. However, I'm *not* an expert on any particular non-SQL storage framework. I'm not in a position to give any sort of meaningful advice on how any particular non-SQL backend will be able to integrate with any particular architectural proposal. People like Eric are in a much better position to answer questions like those. When the 1.3 development cycle starts, I will evaluate the proposals on the table. And - as I've said before - a proposal isn't "merge this branch". It also includes enough discussion and description to convince me (and others) that the solution described by a proposal is correct. > As Thomas said, I just wanted to know whether you'd suggest going on > with our SQLCompiler-based solution and I'd like to know what you > think about it in general. Or is it too early to say anything? Honestly, I have no idea. You're the ones that will need to evaluate if a SQLCompiler-based solution is feasible. Investigate, work out what complications and limitations exist (for GAE and for other backends), and report back in the form of a concrete proposal. If you want my gut reaction, I would suggest that interpreting a SQL-focussed data structure doesn't strike me as a particularly workable solution for backends that don't expose a pseudo-SQL interface. However, I may also be completely wrong. Your task is to convince me, the core team, and the rest of Django community that what you have proposed will be sufficient to solve the problem in the general case. I will say that I like the simplicity of the SQLCompiler approach - the QueryData approach of adding yet another layer between Query and final query language really doesn't appeal to me. However, architectural simplicity ain't worth a hill of beans if it doesn't do the job it needs to do. 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.
