I've pushed an initial PR [1], sadly I had to change one of the signatures.
But I think this is an okayish change for 2.0 given that it is internal API
anyways.
Cheers,
Florian
https://github.com/django/django/pull/8487/
On Tuesday, May 9, 2017 at 3:24:46 PM UTC+2, Florian Apolloner wrote:
>
>
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.
Agreed. As mentioned on IRC, _alter_field() should really be cleaned up.
It's also private API and only called from alter_field() I think. And as
long alter_field()'s API stays backwards compatible you're pretty much
free to do what you need with _alter_field().
/Markus
On 05/09/2017 09:23 PM, ch
Hey Florian,
I think both options are viable.
The main issue with a feature flag would be that it isn't tested by our CI.
I guess we
could make it True on SQLite and have it call remake_table to have some
tests rely
on it or mock it to True in tests and make sure everything goes well.
In all c
I am currently trying to (again?) write a database backend for Informix. So
far so good, but I am running into one major issue: All of Django's other
databases support changing null/default properties via "ALTER TABLE ALTER
col DROP NULL/DEFAULT" or what not. In Informix I can only use "ALTER TA
