This has probably been discussed at great length previously... but my 2c follows:
If you are using a column/doc store you are trying to solve a different problem than if you are using an SQL db. How important is 100% interop? Surely it's about documenting the differences between them and providing an interface to document stores that isn't completely foreign to people who know how to use the django ORM? In which case it seems that the trust issue Russ was talking about earlier is the main barrier here. We need more trusted people to be using the non-rel code. Surely that doesn't mean the project should end. Maybe there is an interim measure that can be taken, like the django project can recommend that people use non-rel when they want column store support in their app with the disclaimer that it is not officially supported. >From there it could become the defacto standard, and following that it may be accepted? Just throwing alternative ideas out here. D On Tue, Sep 28, 2010 at 9:22 AM, Russell Keith-Magee <[email protected]> wrote: > On Tue, Sep 28, 2010 at 1:51 AM, Mark Bucciarelli <[email protected]> wrote: >> On Sat, Sep 25, 2010 at 10:21:06PM +0800, Russell Keith-Magee wrote: >>> >>> 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. >>> >> >> I've seen references to Django's test suite on this list in the past, >> and I'm curious why the criteria can't simple be: "a clean run on our >> test suite." >> >> I have a backend [1] for MonetDB (a column store DB). They expose a SQL >> wrapper around their non-SQL engine, which makes it pretty easy to >> support. >> >> On my todo list was to see how it fares with the Django test-suite. >> I guess the test suite must not cover all the basees, making it a >> necessary but not sufficient criteria for inclusion? >> >> Correct? > > Well, sort of. > > The problem is that NoSQL stores don't necessarily have feature parity > with relational databases. For example, the concept of a join is > pretty fuzzy when it comes to stores like MongoDB and GAE. You *could* > emulate join with a series of lookups, but that could get pretty > spectacularly inefficient, so we're not going to force stores to > emulate behaviors that aren't extensions of their native capabilities. > Given that there isn't feature parity, Django's test suite won't be > able to pass completely. > > We're in the process of migrating Django's test suite to use > unittest2, which, in turn, means we have access to the @skipif and > @skipunless decorators; we're going to be annotating a bunch of tests > to make them 'feature aware' (e.g., don't run this test if the backend > doesn't support transactions). A logical extension of this is to add > other feature checks like "backend supports joins", and annotate the > test suite appropriately. This would allow the noSQL backend to pass > the suite, albeit with a lot of test skips. > > My (mild) concern with this approach is that a feature that this will > make it too easy to get a suite 'passing', and we'll miss some detail > in the process. For example, if we make it easy to skip the aggregates > tests, and a backend actually does support aggregates, then it becomes > easy to say "Oh, we *could* do aggregates, but we just haven't yet". > Now, this may be entirely true, but it could also be the case that > Django's backend API is structured in such as way that aggregates are > impossible to implement. Making it easy to skip tests masks the > complications that may exist in the API. > > 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. > > -- 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.
