Opened 10 years ago
Last modified 4 years ago
#26399 closed Cleanup/optimization
Migration refactoring - to facilitate third-party backend integration — at Initial Version
| Reported by: | Maximiliano Robaina | Owned by: | nobody |
|---|---|---|---|
| Component: | Migrations | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | no | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
I humbly think that django migration api need a some refactoring to facilitate third-party backend integration.
For instance, add_field method [1], 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 disscusion about this en google groups
https://groups.google.com/forum/#!topicsearchin/django-developers/migrations$20firebird/django-developers/yZ0IWGT2qZQ
[1] https://github.com/django/django/blob/master/django/db/backends/base/schema.py#L373