Opened 4 weeks ago

Last modified 4 weeks ago

#28809 assigned Bug

Changing SRID on geometry field doesn't create working migration

Reported by: Jani Tiainen Owned by: Sergey Fedoseev
Component: GIS Version: master
Severity: Normal Keywords: migrations gis
Cc: Sergey Fedoseev Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

When changing SRID of geometry field:

before:

class AddressLog(models.Model):
    location = models.PointField(blank=True, null=True, srid=4326)

after:

class AddressLog(models.Model):
    location = models.PointField(blank=True, null=True, srid=3067)

Migration:

class Migration(migrations.Migration):

    dependencies = [
        ('myapp', '0002_auto_20171114_1021'),
    ]

    operations = [
        migrations.AlterField(
            model_name='addresslog',
            name='location',
            field=django.contrib.gis.db.models.fields.PointField(blank=True, null=True, srid=3067),
        ),
    ]

Traceback:

(myapp) jtiai@jns42-l:~/projects/myproject (default) $ ./manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, sessions, myapp
Running migrations:
  Applying myapp.0003_auto_20171117_0641...Traceback (most recent call last):
  File "./manage.py", line 22, in <module>
    execute_from_command_line(sys.argv)
  File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-packages/django/core/management/__init__.py", line 364, in execute_from_command_line
    utility.execute()
  File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-packages/django/core/management/__init__.py", line 356, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-packages/django/core/management/base.py", line 283, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-packages/django/core/management/base.py", line 330, in execute
    output = self.handle(*args, **options)
  File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-packages/django/core/management/commands/migrate.py", line 204, in handle
    fake_initial=fake_initial,
  File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-packages/django/db/migrations/executor.py", line 115, in migrate
    state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
  File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-packages/django/db/migrations/executor.py", line 145, in _migrate_all_forwards
    state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
  File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-packages/django/db/migrations/executor.py", line 244, in apply_migration
    state = migration.apply(state, schema_editor)
  File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-packages/django/db/migrations/migration.py", line 129, in apply
    operation.database_forwards(self.app_label, schema_editor, old_state, project_state)
  File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-packages/django/db/migrations/operations/fields.py", line 216, in database_forwards
    schema_editor.alter_field(from_model, from_field, to_field)
  File "/home/jtiai/.virtualenvs/myapp/lib/python3.6/site-packages/django/db/backends/base/schema.py", line 494, in alter_field
    (old_field, new_field),
ValueError: Cannot alter field myapp.AddressLog.location into myapp.AddressLog.location - they do not properly define db_type (are you using a badly-written custom field?)

Using Spatialite as backend engine.

Change History (4)

comment:1 Changed 4 weeks ago by Claude Paroz

Component: Database layer (models, ORM)GIS
Triage Stage: UnreviewedAccepted
Version: 1.11master

Changing the SRID of a field is something that's hard to do when you have existing content. I don't think databases are doing anything clever when you do that (e.g. they don't convert the existing values, AFAIK). Probably the best strategy is to create a new column, move the values, converting them in the new SRID in the process, and delete the old column. The strategy might differ depending on the backend.

comment:2 Changed 4 weeks ago by Jani Tiainen

True, SRID change migrations is not easy to do (might not even be possible sometimes due missing conversion parameters). But case should be handled much more gracefully than throwing out traceback.

comment:3 Changed 4 weeks ago by Sergey Fedoseev

Cc: Sergey Fedoseev added

comment:4 Changed 4 weeks ago by Sergey Fedoseev

Owner: changed from nobody to Sergey Fedoseev
Status: newassigned
Note: See TracTickets for help on using tickets.
Back to Top