I see where you are coming from, but I'm not sure it will have the intended effect. One of the great things about Django is that for the most part database features work everywhere. If we split them out there will be more innovation, sure, but we may loose the 'database transparency' we currently have leading to inconsistencies.
It may also be harder to coordinate changes across databases that require changes to core. On your point about non-standard backends, maybe we should focus on making it easier to add third party backends and standardize some of the internals? We could treat the backend as external (i.e no special hacks for them) but keep them in the Django package. If we make the interfaces a bit more abstract it would be a lot easier for these backends to exist without hacks perhaps. As with everything, it's a trade off. I'm not sure there is a clear answer or better solution for all cases than we currently have. On Mon, 26 Nov 2018, 08:57 Johannes Hoppe <i...@johanneshoppe.com wrote: > I want to address a completely different point, and that *innovation*. I > believe that 3rd party backends could lead to more innovation in the Django > ORM. > Currently if you want to introduce a new feature for your database, you > are faced with a lot of complications added by databases you might not be > familiar with. Furthermore you might be requested to makes those features > available for databases you haven't used before. This drastically increases > the bar for contributing innovative new features. As an example, I wanted > to add database defaults for Postgres and multiple insert return values. I > finished the postgres feature in 2 sprints, but it took me another half > year to implement the same for Oracle. Mainly because I never used Oracle > before. > > Beyond that I see that the sheer effort to remove the backends from core > could lead to better design. We currently assume that all databases speak > some flavor of Std SQL, which isn't even true for the currently supported > databases and certainly not for the verify famous mongo-db backend. > > In conclusion, more separation will lead to more diversity. But that is a > good thing, something to embrace and can lead to great results. I would > even go as far as to kick Postgres out too, contrary to what Florian > suggested. I believe Postgres could benefit from a separate package. > > I think Django has the best ORMs and us being able to make changes and > innovate, can ensure that this is still true a decade from now. > > On Friday, March 15, 2013 at 3:29:29 PM UTC+1, VernonCole wrote: >> >> My organization just hit a use case where we need MS-SQL support. >> >> I am jumping on board, so there are at least two of us who can do >> maintenance. >> >> I must say that I would prefer quasi-supported status (akin to admin >> and geodjango) rather than actually being in the core. I think it would >> be a better fit for most situations. We will always be a small minority >> of >> django users. I would just like some assurance that pull requests needed >> to provide good hook support for external database backends got prompt >> attention from the core developers. >> -- >> Vernon Cole >> >> On Thursday, March 7, 2013 6:46:18 PM UTC+1, Jacob Kaplan-Moss wrote: >>> >>> On Wed, Mar 6, 2013 at 3:22 AM, Marc Tamlyn <marc....@gmail.com> wrote: >>> > I don't know why Oracle is included and MSSQL is not [...] >>> >>> It's essentially because a group of people made a concerted effort to >>> get the Oracle backend up to snuff (around the 1.0 timeline, I think?) >>> and then committed to maintaining it. Lately the original people who'd >>> made that commitment have dropped off a bit, but there's always been >>> enough attention to keep it up to date. >>> >>> If someone -- preferably a group -- stepped up and committed to >>> keeping a MSSQL backend up-to-date in core, I'd be +1 on merging it >>> and giving those people commit access to keep it up to date. >>> >>> [This is me speaking personally, not as a BDFL. It'd have to be a >>> discussion, not just my fiat.] >>> >>> Jacob >>> >> -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/978f91f8-709a-48dc-b2e2-b940e19a9f7f%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/978f91f8-709a-48dc-b2e2-b940e19a9f7f%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFNZOJN5r%3DcbmCDBbfPprTOgE0j%2BvPczbhi%3D0m6eH7vir%2BC5DQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
