Opened 4 years ago

Closed 4 years ago

#23085 closed Bug (fixed)

AlterField/RenameField doesn't work on GIS fields on PostGIS 1.5

Reported by: jgoclawski Owned by: Andrew Godwin
Component: Migrations Version: 1.7-rc-1
Severity: Release blocker 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

Steps to reproduce:

  1. Have PostGIS version 1.5, GeoDjango properly configured, etc., Django version 1.7b3
  2. Create a simple model:
from django.contrib.gis.db import models


class Example(models.Model):
    coordinates = models.PointField(blank=True, null=True, srid=4326)


  1. Create initial migrations
  2. Change model to:
from django.contrib.gis.db import models


class Example(models.Model):
    coordinates = models.PointField(blank=True, null=True, srid=4326, db_column='coordinates')


  1. Generate an automatic migration, which will look something like this:
# encoding: utf8
from __future__ import unicode_literals

from django.db import models, migrations
import django.contrib.gis.db.models.fields


class Migration(migrations.Migration):

    # dependencies

    operations = [
        migrations.AlterField(
            model_name='example',
            name='coordinates',
            field=django.contrib.gis.db.models.fields.PointField(db_column='coordinates', srid=4326, blank=True, null=True),
        ),
    ]
  1. Run migrate

Result:

Traceback (most recent call last):
  File "/[... truncated ...]/lib/python3.3/site-packages/coverage/execfile.py", line 104, in run_python_file
    exec_code_object(code, main_mod.__dict__)
  File "/[... truncated ...]/lib/python3.3/site-packages/coverage/backward.py", line 93, in exec_code_object
    exec(code, global_map)
  File "/[... truncated ...]/bin/django-admin.py", line 5, in <module>
    management.execute_from_command_line()
  File "/[... truncated ...]/lib/python3.3/site-packages/django/core/management/__init__.py", line 427, in execute_from_command_line
    utility.execute()
  File "/[... truncated ...]/lib/python3.3/site-packages/django/core/management/__init__.py", line 419, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/[... truncated ...]/lib/python3.3/site-packages/django/core/management/base.py", line 288, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/[... truncated ...]/lib/python3.3/site-packages/django/core/management/base.py", line 337, in execute
    output = self.handle(*args, **options)
  File "/[... truncated ...]/lib/python3.3/site-packages/django_jenkins/management/commands/__init__.py", line 89, in handle
    if test_runner.run_tests(test_labels):
  File "/[... truncated ...]/lib/python3.3/site-packages/django/test/runner.py", line 147, in run_tests
    old_config = self.setup_databases()
  File "/[... truncated ...]/lib/python3.3/site-packages/django_jenkins/runner.py", line 161, in setup_databases
    return super(CITestSuiteRunner, self).setup_databases()
  File "/[... truncated ...]/lib/python3.3/site-packages/django/test/runner.py", line 109, in setup_databases
    return setup_databases(self.verbosity, self.interactive, **kwargs)
  File "/[... truncated ...]/lib/python3.3/site-packages/django/test/runner.py", line 297, in setup_databases
    verbosity, autoclobber=not interactive)
  File "/[... truncated ...]/lib/python3.3/site-packages/django/db/backends/creation.py", line 368, in create_test_db
    test_database=True)
  File "/[... truncated ...]/lib/python3.3/site-packages/django/core/management/__init__.py", line 167, in call_command
    return klass.execute(*args, **defaults)
  File "/[... truncated ...]/lib/python3.3/site-packages/django/core/management/base.py", line 337, in execute
    output = self.handle(*args, **options)
  File "/[... truncated ...]/lib/python3.3/site-packages/django/core/management/commands/migrate.py", line 146, in handle
    executor.migrate(targets, plan, fake=options.get("fake", False))
  File "/[... truncated ...]/lib/python3.3/site-packages/django/db/migrations/executor.py", line 62, in migrate
    self.apply_migration(migration, fake=fake)
  File "/[... truncated ...]/lib/python3.3/site-packages/django/db/migrations/executor.py", line 96, in apply_migration
    migration.apply(project_state, schema_editor)
  File "/[... truncated ...]/lib/python3.3/site-packages/django/db/migrations/migration.py", line 107, in apply
    operation.database_forwards(self.app_label, schema_editor, project_state, new_state)
  File "/[... truncated ...]/lib/python3.3/site-packages/django/db/migrations/operations/fields.py", line 132, in database_forwards
    schema_editor.alter_field(from_model, from_field, to_field)
  File "/[... truncated ...]/lib/python3.3/site-packages/django/db/backends/schema.py", line 484, in alter_field
    if old_type is None and new_type is None and (old_field.rel.through and new_field.rel.through and old_field.rel.through._meta.auto_created and new_field.rel.through._meta.auto_created):
AttributeError: 'NoneType' object has no attribute 'through'

Reason (my guess):
django.contrib.gis.db.models.fields.GeometryField.db_type (used by alter_field as old_field.db_parameters):

def db_type(self, connection):
        return connection.ops.geo_db_type(self)


django.contrib.gis.db.backends.postgis.operations.geo_db_type returns None for PostGIS 1.5, which causes above exception

Change History (7)

comment:1 Changed 4 years ago by jgoclawski

It was tested on django master from github as well (Django version 1.7b3 mentioned in description)

comment:2 Changed 4 years ago by Tim Graham

Triage Stage: UnreviewedAccepted

comment:3 Changed 4 years ago by Claude Paroz

Considering the complexity of changing PostGIS 1.x columns and the fact that PostGIS 1.x will die in a not-so-long future, I think we should simply gracefully fail and document that changing PostGIS 1.x columns is unsupported.
Of course, if someone wants to work on that, patches are welcome, as usual.

comment:4 Changed 4 years ago by Tim Graham

Severity: Release blockerNormal

Removing release blocker flag in light of that analysis.

comment:5 Changed 4 years ago by Claude Paroz

Severity: NormalRelease blocker

Sorry, but not crashing is a release blocker IMHO. As soon as we fail gracefully, we can remove the release blocker flag.

comment:6 Changed 4 years ago by Andrew Godwin

Owner: changed from nobody to Andrew Godwin
Status: newassigned

I'll make this fail with a nicer error message and mark it as solved - that way it's not crashing and thus not a release blocker (and it's not a regression as you couldn't alter fields before 1.7)

comment:7 Changed 4 years ago by Andrew Godwin <andrew@…>

Resolution: fixed
Status: assignedclosed

In 3268711417b3c67f6eb08bec3f39f2d51186e11b:

[1.7.x] Fixed #23085: Better error message for PostGIS 1.5/bad custom fields

Note: See TracTickets for help on using tickets.
Back to Top