On Sat, Sep 25, 2010 at 8:47 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > Hi, > in my last discussion on django-users Russell told me that he'd like > to see four proof-of-concept (or better) backends before considering > NoSQL for inclusion in trunk.
The number 4 wasn't actually the important bit - it was that I want to see a range of noSQL approaches represented. I don't want to see 4 key-value stores; I want to see a key-value store, and a document store, and a column store, etc. I need to see that the API is rich enough to cover all noSQL bases. > The primary point was that enough > eyeballs have looked at the API, first. Now we finally have four > backends for Django-nonrel: > > App Engine (used in production), developed by Thomas Wanschik and me > http://www.allbuttonspressed.com/projects/djangoappengine > > MongoDB (used in production), developed by Flavio Percoco Premoli, > Alberto Paro, George Karpenkov, and me > http://github.com/FlaPer87/django-mongodb-engine > > Cassandra (alpha/experimental), developed by Rob Vaterlaus with very > minor hints from me > http://github.com/vaterlaus/django_cassandra_backend > > ElasticSearch (alpha/experimental), developed by Alberto Paro > http://github.com/aparo/django-elasticsearch > > All of them are based on our nonrel backend API (djangotoolbox.db). It > should be relatively easy to extend the API to support both > Django-nonrel and Alex' query-refactor branch at the same time. The > backends will probably only need minor changes, if at all. > > Russell and the rest of the Django core team, if we make those four > backends, developed with 12 eyeballs ;) work on the query-refactor > branch, what else is necessary to get NoSQL support into trunk? Please > don't tell me that you also want a CouchDB backend. :( > > My only requirement before porting the backends is that the > (Native)AutoField issue gets resolved, first. That will simplify our > porting effort and allow us to reuse our existing unit tests and > project code. Firstly, I need to see these backends actually implemented on query-refactor. Secondly, I need to have a better understanding of what is meant when you say "alpha/experimental" or "in production" support for a backend. I have no doubt that you can get any backend working for simple cases. I have no doubt that those simple cases may well be sufficient for certain production purposes. It's the complex cases that have me concerned. I need to know that a user of <insert NoSQL backend> won't be overwhelmingly surprised if they try to use Django to access their data store. What data store features features are and aren't supported? When a feature isn't supported, is this due to conceptual problems mapping the store onto the ORM, technical limitations of the store itself, or technical limitations imposed by the query-refactor branch? When a feature *is* supported, is it supported in a way that makes conceptual sense? To counter this, I would like to see a comprehensive summary of the state of play of the level of support for each storage backend. This includes: * How the ORM maps to the backend * Capabilities that are lost as a result of this mapping * Capabilities that have been implemented, and how * Capabilities that can't/haven't be implemented (and why) Features like CSRF and session messages maintained wiki pages with this sort of problem analysis prior to their merge to trunk. This serves as excellent design documentation describing why the feature is the way it is. I'd like to see an analogous page for query-refactor. Thirdly, I'd like to see some independent verification of the claims being made. It's fine to have the person who wrote a particular backend saying "feature XYZ is complete", but I'd like to see independent verification of this fact -- preferably from someone known to the core team, not just a random stranger. The panelists at the DjangoCon 2010 NoSQL panel would be a good starting place to look for this sort of verification, but they're certainly not the only candidates. My reason for wanting this is that I'm simply not an expert in any of these backends. I know SQL quite well, but I haven't had occasion to try out other backends in depth. I can judge the technical merits of a patch based on what I know, but I don't want to make a judgement based on incompletely knowledge. I need to rely on those that I know and trust to give me confidence that nothing has been missed. Lastly, we need to resolve the AutoField problem. This is the biggest outstanding technical issue. I can't say I've got any particularly brilliant ideas on how to solve it. Suggestions are welcome. As for timing: I'm on record saying a number of times now that this isn't something I'm targeting for 1.3. We need to have a release that is low on features and high on bugfixes. Given the time required to make large scale database backend changes, I simply don't have enough bandwidth to satisfy the community needs for 1.3 *and* the needs of query-refactor. However, if people like yourself that are motivated in this are can get the pieces in place during the 1.3 development cycle, query-refactor could be an early delivery in the 1.4 timeframe (i.e., early next year). 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.
