On Fri, Mar 8, 2013 at 7:57 AM, Alex Ogier <[email protected]> wrote:
> Here's something I've been thinking about: > > As a rule, assuming that backends are not bug-riddled and do not have > needlessly shoddy performance, nearly all of the value of an ORM is in the > set of frontend features it exposes to application developers. Given a > certain frontend API, then the only value in iterating the backend > independently from the frontend is to fix uncaught bugs, or to improve > performance, there's no value in adding features. > > Also as a rule, adding features to a frontend independently from the > backend has little value. Without an implementation in whatever backend you > are on, it only serves as a guide for future backend development, so you > might as well push for backends to catch up in the same release cycle. (Or > the feature doesn't require backend support, but then it doesn't hurt to > reversion the backend anyways). > > So basically, there's not much value in independently versioning and > maintaining frontends and backends to the ORM. This is in contrast to, say, > localflavor, where an improvement in Mongolian localization can immediately > help every Mongolian website in every Django version. So this primary > motivation for independent maintenance is not a factor in the ORM. Hence I > think the core team should include as many backends as it can handle in > core (where "handle" means test that they function properly for each > release). Oracle had been slipping, but from what I understand it's now in > the CI server and back to passing most tests. > > So I see no reason to split off backends unless the maintenance burden is > such that they are chronically broken in every Django release. And every > reason to add MSSQL unless the maintenance burden is too high. > And that last clause is the catch. I completely agree with Jacob's analysis of the status quo, and I agree largely with his position on having MSSQL in the core. I'd have no problem seeing MSSQL in the core - it's at least as high profile as Oracle, and although the demand for a MSSQL backend is restricted to a particular subset of the community, there is at least *some* demand for it to exist. Having MSSQL in core would allow us to hold our head high and say we support Microsoft platforms. Microsoft is even a member of the DSF at this point, so they're at least notionally interested in Django as a platform. The maintenance burden is the problem. Historically, we've already had to *remove* a MSSQL backend because of bit rot (see [1]) - this isn't a pattern I want to repeat in the future. I don't want to add a backend to core unless I'm *certain* that it will see long term maintenance. [1] https://github.com/django/django/commit/c30a050e41 There is, however, a possible middle ground, following the example set by Flask: we introduce to Django a list of "officially recognised" extensions. These extensions are still maintained as external projects, but the core team promise to include these projects as part of the testing regimen for a release. If the MSSQL backend were recognised like this, we would run the full Django test suite against the MSSQL backend, and if that testing revealed a bug in the test suite which was identified as being due to a change in Django's codebase, that bug would be a release blocker (Bugs in the backend itself would still be the backend's responsibility, and not release blocking on Django) Looking outside database backends, this could also apply to high-profile projects like haystack, django-registration, and so on. This would also serve to highlight projects in our community that are 'defacto standards', or good examples of reusability, without needing to expand the core team or the size of contrib, and show that the core project is explicitly interested in the broader ecosystem. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
