[Django] #26399: Migration refactoring - to facilitate third-party backend integration
Django
-------------------------------+--------------------
Reporter: maxirobaina | Owner: nobody
Type: Uncategorized | Status: new
Component: Migrations | Version: master
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
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
--
Ticket URL: <https://code.djangoproject.com/ticket/26399>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
--------------------------------------+------------------------------------
Reporter: maxirobaina | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
* type: Uncategorized => Cleanup/optimization
* stage: Unreviewed => Accepted
Old 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
New description:
I humbly think that django migration api need a some refactoring to
facilitate third-party backend integration.
For instance, the
[https://github.com/django/django/blob/14e6823d090a077d27f9f7caff2d505db31e55a7/django/db/backends/base/schema.py#L373
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.
[https://groups.google.com/d/topic/django-
developers/yZ0IWGT2qZQ/discussion A discussion about this on django-
developers].
--
Comment:
It will be easiest to move forward with this if you can submit a pull
request with a proposal.
--
Ticket URL: <https://code.djangoproject.com/ticket/26399#comment:1>
Django
--------------------------------------+------------------------------------
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by maxirobaina):
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
--
Ticket URL: <https://code.djangoproject.com/ticket/26399#comment:2>
Django
--------------------------------------+------------------------------------
Type: Cleanup/optimization | Status: new
Component: Migrations | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/26399#comment:3>
Django
Reporter: Maximiliano Robaina | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Migrations | Version: dev
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Adam Johnson):
* status: new => closed
* resolution: => needsinfo
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/26399#comment:4>