On Wed, Apr 7, 2010 at 5:55 PM, Waldemar Kornewald <wkornew...@gmail.com> wrote: > On Wed, Apr 7, 2010 at 5:22 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: >>> Other issues that spring to mind: >>> >>> * What about nonSQL datatypes? List/Set types are a common feature of >>> Non-SQL backends, and are The Right Way to solve a whole bunch of >>> problems. How do you propose to approach these datatypes? What (if >>> any) overlap exists between the use of set data types and m2m? Is >>> there any potential overlap between supporting List/Set types and >>> supporting Arrays in SQL? >>> >> >> Is there overlap between List/Set and Arrays in SQL? Probably. In my >> opinion there's no reason, once we have a good clean seperation of >> concerns in the architecture that implementing a ListField would be >> particularly hard. If we happened to include one in Django, all the >> better (from the perspective of interoperability). > > Do all SQL DBs provide an array type? PostgreSQL has it and I think it > can exactly mimic NoSQL lists, but I couldn't find an equivalent in > sqlite and MySQL. Does this possibly stand in the way of integrating > an official ListField into Django or is it OK to have a field that > isn't supported on all DBs? Or can we fall back to storing the list > items in separate entities in that case? >
I'd be -1 on using a separate entity, if it's supported it is, if not it's not. There's no reason it has to be included in Django in any event (certainly none of the non-relational backends will be, at least to start with). >>> * How does a non-SQL backend integrate with syncdb and other setup >>> tools? What about inspectdb? >>> >> >> Most, but not all non-relational databases don't require table setup >> the way relational DBs do. MongoDB doesn't require anything at all, >> by contrast Cassandra requires an XML configuration file. How to >> handle these is a little touchy, but basically I think syncdb should >> stay conceptually pure, generating "tables", if extra config is needed >> backends should ship custom management commands. > > Essentially, I agree, but I would add things like auto-generated > CouchDB views to the syncdb process (since syncdb on SQL already takes > care of creating indexes, too). > >>> * Why the choice of MongoDB specifically? Do you have particular >>> experience with MongoDB? Does MongoDB have features that make it a >>> good choice? >>> >> >> MongoDB offers a wide range of filtering options, which from my >> perspective means it presents a greater test of the flexibility of the >> developed APIs. For this reason GAE would also be a good choice. >> Something like Riak or Cassandra, which basically only have native >> support for get(pk=3) would be a poor test of the flexibility of the >> API. > > MongoDB really is a good choice. Out-of-the-box (without manual index > definitions) it provides more features than GAE and most other NoSQL > DBs. MongoDB and GAE should also have the simplest backends. > > Why should the Cassandra/CouchDB/Riak/Redis/etc. backend only support > pk=... queries? There's no reason why the backend couldn't maintain > indexes for the other fields and transparently support filters on any > field. I mean, you don't really want developers to manually create and > query separate indexing models for mapping one field value to its > respective primary key in the primary model table. We can do much > better than that. > Because that's all they support out of the box. You call it maintaining an index, but it really means setting up a separate "table" (in RDBMS parlance) and I think that's a level of emulation that's far beyond what should be supported out of the box. In any event I can't stop someone from writing a backend that does do that level of abstraction. >>> * Given that you're only proposing a single proof-of-concept backend, >>> have you given any thought to the needs of other backends? It's not >>> hard to envisage that Couch, Cassandra, GAE etc will all have slightly >>> different requirements and problems. Is there a common ground that >>> exists between all data store backends? If there isn't, how do you >>> know that what you are proposing will be sufficient to support them? >>> >> >> To a certain extent this is a matter of knowing the featuresets of the >> databases and, hopefully, having a mentor who is knowledgeable about >> them. The reality is under the GSOC time constraints attempting to >> write complete backends for multiple databases would probably be >> impossible. > > Well, you might be able to quickly adapt the MongoDB backend to GAE > (within GSoC time constraints) due to their similarity. Anyway, there > is common ground between the NoSQL DBs, but this highly depends on > what problem we agree to solve. If we only provide exactly the > features that each DB supports natively, they'll appear dissimilar > because they take very different approaches to indexing and if this > isn't abstracted and automated NoSQL support doesn't really make sense > with Django. OTOH, if the goal is to make an abstraction around their > indexes they can all look very similar from the perspective of > Django's ORM (of course they have different "features" like sharding > or eventual consistency or being in-memory DBs or supporting fast > writes or reads or having transactions or ..., but in the end only few > of these features have any influence on Django's ORM, at all). > > Bye, > Waldemar Kornewald > > -- > 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. > > Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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.
