Re: Proposal: django.contrib.mysql

> > How about making the package official extension and bring under django org? > I thought about this, but a few parts of Django-MySQL are incredibly hacky and should probably not be "officially supported code".

Re: raise error for form attribute

clean() and non_field_error both seem like the wrong place since they happen after the first rendering of the form. You should be able to raise it on initialization, no? On 10 May 2017 at 10:19, Naveen Yadav wrote: > Hi, > > I am working on my first issue >

Re: Proposal: django.contrib.mysql

On Monday, May 8, 2017 at 4:22:04 PM UTC+1, Adam Johnson wrote: > Sérgio, django-mysql already fully supports MySQL 5.7's JSON type with > its JSONField: > https://django-mysql.readthedocs.io/en/latest/model_fields/json_field.html > . Try that. > yes , I'm using it now and works great, many

raise error for form attribute

Hi, I am working on my first issue . Part of solution seems like 1. checking the concerned fields 2. raising the error if required After going through the source code, I realized there two ways to resolve the issue, first one seems raise error at

Re: Problems around SchemaEditor._alter_field

I agree that *_alter_field *should be refactored, because currently is unmaintainable or at least really hard to maintain. I checked and some of the official 3rd-party database backends [1] use this private API i.e. django-mssql [2], django-firebird [3]. Maybe we should take that into account.

Re: DEP pre-proposal for a simpler URLs syntax.

On Wednesday, May 3, 2017 at 12:35:30 AM UTC+2, Marten Kenbeek wrote: > > > >> >>- The more complex part is (I think) figuring out how to deal with >>cases where we have a `path('/', include(other_urls))` and >>`other_urls` also has a `path()` mentioning `something`. However this >