Refactor SchemaEditor to facilitate Firebird handlings of column defaults

[Maximiliano Robaina]

I humbly think that django migration api need a some refactoring to facilitate third-party backend integration.

For instance, the ​SchemaEditor.add_field() method, if I try to delete a default value on a column that does not have a previous default value definition I get an error on firebird, for which reason, I need to check if that field has got defined a default value before. Then I need to rewrite the whole add_field method too.

Maybe a possible approach would be to have sql templates (sql_alter_column_default, sql_alter_column_no_default, etc.) as methods, instead of class attributes.

​A discussion about this on django-developers.

[Tim Graham]

It will be easiest to move forward with this if you can submit a pull request with a proposal.

[Maximiliano Robaina]

Hi timgraham,
Thanks for response, but is firebird the only one third-party backend with this problem?
I don't think so, you can check in [1] the need to override some privante methods.
I named alter_column_default as an example but change nullability into _alter_field method is a use case too.

[1] ​https://bitbucket.org/Manfre/django-mssql/src/24ef16a3c7d0e157ebd26f96b561e812c5ebc07b/sqlserver_ado/schema.py?at=master&fileviewer=file-view-default#schema.py-153

[Tim Graham]

I don't know but the ticket description is too vague about what exactly should be done. I don't think anyone except a maintainer of or contributor to a third-party backend is in a good position to complete this task.

[Adam Johnson]

I think this ticket can be closed since there is no further detail. Also, one can at least sql_create_column to a special object that performs extra processing on %, or modify self.execute() to alter the SQL before execution.