Hi, On Tuesday 05 March 2013, Michael Manfre wrote: > Full disclosure, I maintain django-mssql and am biased toward having all > database backends treated as if they were 3rd party backends. >
In recent years, I have been the main contributor to South's MSSQL and Oracle backends. I am biased towards having MSSQL treated as an equal to the database systems supported in core, but also towards support of backend-specific low- level code in user apps. Also, I am a Linux user -- I use django-pyodbc for my work on South, not django-mssql. > > 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. > I think you are missing something crucial: Django depends on its commonly-used backends. A critical problem with the Postgresql or MySql backend is a critical problem for the Django project, regardless of separation to repositories. And where the dependency is weaker, being in core was not a guarantee for fixes -- Django carried significant Oracle problems for quite long, and they were just not deemed crucial. So, IMO, you can't escape the need to have a set of "blessed" backends, which core is committed to their correct functioning, and thus need to be, at least to some degree, in sync with the Django main project. > - 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. > These benefits are, IMO, orthogonal to the separation you suggest. I can't speak for core, but I doubt that a proposed change to make the database API more robust and flexible will be rejected just because it is originally motivated by a 3rd-party, rather than core, backend. > Concerns > ======= > > - Less popular database backends may get left behind > I am worried that the result of such change will not be that MSSQL is treated as well as Postgres is today, but that Oracle is treated as bad as MSSQL is today. > > 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. South certainly does, I'm sure it's not the only one. Shai. -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
