Opened 10 years ago

Closed 10 years ago

#22451 closed Bug (fixed)

Migrations do not work with GeoDjango

Reported by: scibi Owned by: Claude Paroz
Component: Migrations Version: 1.7-beta-1
Severity: Release blocker Keywords:
Cc: scibi Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Hi,

I had a model:

from django.contrib.gis.db import models
from django.utils.translation import ugettext_lazy as _

class RoadFragment(models.Model):
    road = models.ForeignKey(Road, verbose_name=_("Road"),
            on_delete=models.PROTECT)
    name = models.CharField(_("Name"), max_length=255)
    description = models.TextField(_("Description"), blank=True)
    beginning_location = models.PointField(verbose_name=_("Beginning location"),
            blank=True, null=True)
    beginning_node = models.IntegerField(_("Beginning node"), blank=True, null=True)
    end_node = models.IntegerField(_("End node"), blank=True, null=True)
    end_location = models.PointField(verbose_name=_("Beginning location"),
            blank=True, null=True)

    objects = models.GeoManager()

I removed end_location field and added 3 other fields:

from django.contrib.gis.db import models
from django.utils.translation import ugettext_lazy as _

class RoadFragment(models.Model):
    road = models.ForeignKey(Road, verbose_name=_("Road"),
            on_delete=models.PROTECT)
    name = models.CharField(_("Name"), max_length=255)
    description = models.TextField(_("Description"), blank=True)
    beginning_location = models.PointField(verbose_name=_("Beginning location"),
            blank=True, null=True)
    beginning_node = models.IntegerField(_("Beginning node"), blank=True, null=True)
    end_node = models.IntegerField(_("End node"), blank=True, null=True)
    check_path = models.LineStringField(_("Check path"), blank=True, null=True)
    check_result = models.BooleanField(_("Check result"), default=False)
    check_time = models.DateTimeField(_("Check time"), blank=True, null=True)


    objects = models.GeoManager()

I've run makemigrations command which generated attached migration file.

$ ./manage.py makemigrations
Migrations for 'roads':
  0003_auto_20140416_0000.py:
    - Add field check_time to roadfragment
    - Add field check_path to roadfragment
    - Add field check_result to roadfragment
    - Remove field end_location from roadfragment

Unfortunately migrate command doesn't create check_path column. There is no error nor warning:

$ ./manage.py migrate roads
Operations to perform:
  Apply all migrations: roads
Running migrations:
  Applying roads.0003_auto_20140416_0000... OK

Before migration table looks like this (PostgreSQL 9.1, sorry for Polish headers):

# \d roads_roadfragment
                                       Tabela "public.roads_roadfragment"
      Kolumna       |          Typ           |                           Modyfikatory                            
--------------------+------------------------+-------------------------------------------------------------------
 id                 | integer                | niepusty domyślnie nextval('roads_roadfragment_id_seq'::regclass)
 road_id            | integer                | niepusty
 name               | character varying(255) | niepusty
 description        | text                   | niepusty
 beginning_node     | integer                | 
 end_node           | integer                | 
 beginning_location | geometry               | 
 end_location       | geometry               | 

After migration it looks like this:

# \d roads_roadfragment
                                        Tabela "public.roads_roadfragment"
      Kolumna       |           Typ            |                           Modyfikatory                            
--------------------+--------------------------+-------------------------------------------------------------------
 id                 | integer                  | niepusty domyślnie nextval('roads_roadfragment_id_seq'::regclass)
 road_id            | integer                  | niepusty
 name               | character varying(255)   | niepusty
 description        | text                     | niepusty
 beginning_node     | integer                  | 
 end_node           | integer                  | 
 beginning_location | geometry                 | 
 end_location       | geometry                 | 
 check_time         | timestamp with time zone | 
 check_result       | boolean                  | niepusty

As you can see end_location was not removed and check_path was not added...
Splitting operation into multiple migrations doesn't work too (I've tried just removing end_location - it wasn't removed).

Attachments (1)

0003_auto_20140416_0000.py (1.1 KB ) - added by scibi 10 years ago.
Migration file

Download all attachments as: .zip

Change History (11)

by scibi, 10 years ago

Attachment: 0003_auto_20140416_0000.py added

Migration file

comment:1 by Claude Paroz, 10 years ago

Severity: NormalRelease blocker
Triage Stage: UnreviewedAccepted

comment:2 by Claude Paroz, 10 years ago

Owner: changed from nobody to Claude Paroz
Status: newassigned

comment:4 by scibi, 10 years ago

Cc: scibi added

comment:5 by Claude Paroz <claude@…>, 10 years ago

In fb09a489ca2c9c8940348e0cafafdbd7aff4740a:

Fixed adding new GIS column in PostGIS 1.x migration

Refs #22451.

comment:6 by Claude Paroz, 10 years ago

Has patch: unset

I'd like to also address this issue with Spatialite.

comment:7 by Claude Paroz <claude@…>, 10 years ago

In 5c19c698b1d84eeaa47d56460d60478b50df6b8c:

[1.7.x] Fixed adding new GIS column in PostGIS 1.x migration

Refs #22451.
Backport of fb09a489c from master.

comment:8 by Claude Paroz <claude@…>, 10 years ago

In 2ffa6ca73a1ecc16cdfa8c03402a17a5c2e2f8cb:

Added Spatialite support to the new migration framework

Refs #22451.

comment:9 by Claude Paroz <claude@…>, 10 years ago

In c3228ef3e213c6149f21ac51648823017c1d9b9f:

[1.7.x] Added Spatialite support to the new migration framework

Refs #22451.
Backport of 2ffa6ca73a from master.

comment:10 by Claude Paroz, 10 years ago

Resolution: fixed
Status: assignedclosed

I cannot say that all is well regarding GeoDjango and migrations, but basic support should now be functional. Feel free to open new tickets for specific issues.

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