Wow I didn't reply for 11 days (sorry, company a bit crazy right now) and features are already being stolen merged! https://github.com/django/django/pull/6292/files :)
> What's your main motivation for wanting to include it in Django itself? > I want Django to work better on MySQL/MariaDB > Do you have a long term interesting in maintaining the module as part of > Django itself? > I've worked with Django on MySQL for 3 years and don't see that ending any time soon. > we have Python’s “standard library is where modules go to die” problem > I'm aware of this, and as you suggest Aymeric, we could just merge the most stable bits. I was thinking anything that's similar to what contrib.postgres supplies is a good idea for inclusion - the fields, lookups, and aggregates are good ideas. Of the fields I think only the JSONField and maybe EnumField are worth it. Also the migration operations for loading plugins might be useful, although they're mostly only useful on MariaDB. For writing a DEP - I just make a PR to https://github.com/django/deps right? I'm happy for JSONField to be made a core field on the condition that it's > underlying support is more than a text blob on all our main databases. It > sounds like this will soon be the case. > Just a warning - I think this would be a very complex field, with lots of internal connection vendor switching. All the DB vendors have done it their own way, more or less :( On Friday, March 4, 2016 at 9:15:02 AM UTC, Marc Tamlyn wrote: > > One of the other reasons why contrib.postgres is in core is that it > required some changes to internals of the ORM. It's possible that all of > those we need are done now (except custom indexes) - is there anything > about contrib.mysql which would benefit from this? > > I'm happy for JSONField to be made a core field on the condition that it's > underlying support is more than a text blob on all our main databases. It > sounds like this will soon be the case. > > Marc > > On 4 March 2016 at 09:04, Josh Smeaton <[email protected] <javascript:>> > wrote: > >> I agree regarding choosing the most most useful bits. When we discussed >> this at DUTH I did mention that there were some features that would be very >> difficult to get included in Django. I guess you'd have to consider whether >> or not you'd be willing to move features from django-mysql into contrib and >> how that might affect django-mysql in the longer term. I really like the >> idea of having a contrib.mysql though, as it shows we're not just committed >> to moving postgres forward. Having a voice for mysql in the team would also >> be very helpful. >> >> Cheers >> >> On Friday, 4 March 2016 18:15:15 UTC+11, Aymeric Augustin wrote: >>> >>> Hi Adam, >>> >>> django-mysql has a rather large API surface. I think the first step >>> would be to make a list of the most stable and generally useful bits that >>> are candidate for inclusion in Django and to write that list down in a DEP. >>> >>> The fields, functions, lookups, and aggregates are good candidates. I’m >>> less sure about the QuerySet extensions because we don’t have anything >>> similar yet. We’d have to think about the implications. >>> >>> Looking forwards, django-mysql could be an experimental ground for >>> features. When they stabilize, the most common features could go into >>> django.contrib.mysql. >>> >>> Since making changes to public APIs is a pain, you only want to put code >>> in Django when it’s done. To a lesser extent, we have Python’s “standard >>> library is where modules go to die” problem. >>> >>> It would obviously help if other community members expressed interest in >>> django.contrib.mysql or, even better, intent to help maintain it in the >>> future. >>> >>> I hope this helps, >>> >>> -- >>> Aymeric. >>> >>> PS: if this plan comes to fruition, most likely you’ll get commit access >>> along the way ;-) >>> >>> >>> On 04 Mar 2016, at 00:09, Adam Johnson <[email protected]> wrote: >>> >>> The *django.contrib.postgres* docs state: >>> >>> There is no fundamental reason why (for example) a contrib.mysql module >>>> does not exist >>> >>> >>> *Well...* over the past year and a bit I've been developing >>> Django-MySQL. It has a ton of features specific to MySQL and/or MariaDB. >>> For a quick tour of the features, see the exposition in the documentation: >>> https://django-mysql.readthedocs.org/en/latest/exposition.html (it's >>> not all suitable for Django core, some is kinda hacky (but well tested!)) >>> >>> At DUTH in November I talked with Josh Smeaton about posting a >>> suggestion here for *django.contrib.mysql*. Since then, I've simply >>> been lazy/forgetful, but now I'm here getting round to it. >>> >>> I'm also a bit motivated by my recent completion of its *JSONField* for >>> MySQL 5.7+ which is very similar to the *contrib.postgres* one, copying >>> and adapting large parts of code from Marc Tamlyn's work. We all know how >>> much everyone loves JSON these days. If anything, this could be a core >>> field rather than a *contrib* one - Oracle and SQLite also have JSON >>> capabilities now. JSON everywhere! >>> >>> Anyway... what's the interest in *django.contrib.mysql*? And where >>> woudl we go from here... >>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> 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/ed9245ea-f908-4c1c-91ad-cb94f0147959%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-developers/ed9245ea-f908-4c1c-91ad-cb94f0147959%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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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/562f8c3e-4bf1-47cf-9a98-1a6f9b171528%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/562f8c3e-4bf1-47cf-9a98-1a6f9b171528%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 [email protected]. To post to this group, send email to [email protected]. 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/67dde25c-f40b-4dc2-8971-65c1da0555a3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
