Full disclosure, I maintain django-mssql and am biased toward having all database backends treated as if they were 3rd party backends.
The current discussion about "Switch to database-level autocommit" ( http://bit.ly/ZlVERI) reminded me of a past discussion regarding moving the database backends out of the core. I don't remember exactly where I heard the discussion, but I'd like to revive it. My proposal is to move all database backends out of Django, except for an sqlite reference implementation. Django has already done a similar transition with django.contrib.localflavor, which provides us with some of the basic answers about whether this sort of thing is possible and a rough guide about how to make it happen. Benefits ====== - One of the biggest benefits of this change would be that database backends will no longer be bound to Django's release cycle and Django would not need to make a dot release for a database specific issue. - This will result in Django having a more flexible/robust database API. Any of the existing complexity imposed on the core by a specific database backend could be abstracted out to the API. - In some instances this will simplify the core's code by pushing the complexity in to the specific database backend. Concerns ======= These are the current issues/concerns faced by 3rd party database backends. - All backends would need to support multiple versions of Django, or at least properly document which versions of Django the backend works with - People will need to (pip) install the database backend that they want for each project - Less popular database backends may get left behind - Each project will have its own tests and will also need to run against the entire Django test suite Migration Path: =========== I believe this can be accomplished without needing a multi-version deprecation cycle because unlike localflavors, there should be very little, if any, user code that imports a specific database backend directly. The only instances I can think of are the DATABSE_ENGINE path and non standard features that I've added to django-mssql; custom field types, non-standard aggregates, etc. If a multi-version deprecation cycle is needed, it will be possible to fix the import paths as localflavors. Django 1.6 or 1.7 - Create separate github project for each database backend and move code - Abstract out any backend specific code in the ORM by extending the database API - Move backend specific tests to appropriate project Regards, Michael Manfre -- 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.
