Ticket #113 (closed defect: wontfix)

Opened 7 years ago

Last modified 16 months ago

Unable to migrate data with schema when creating geometry fields

Reported by: benjamin.c.burns@… Owned by: andrew
Priority: major Milestone: 0.5
Component: databaseapi Version: 0.6-pre
Keywords: Cc:


I am trying to migrate my model by adding a PointField? from django.contrib.gis.db.models. Upon committing the transaction and opening a new one, the column has still not been created. I believe this occurs because the support for these fields is implemented using the "deferred sql" feature of the generic db class.

My current workaround is to separate out the migration of any GIS fields from normal fields, write a normal migration for the normal fields, and then build two additional migrations, one that handles the schema, and one that handles the data.

This is a bit tedious, and while it works it seems semantically invalid to separate it out into multiple migrations. The biggest problem I see with this is that later on if I need to roll back I'll need to remember not to roll back to one of the intermediate migrations. Not a major issue, but still an annoyance.

Change History

comment:1 Changed 7 years ago by andrew

  • Status changed from new to closed
  • Version set to subversion
  • Resolution set to wontfix
  • Milestone set to 0.5

Having to do separate schema and data migrations is a fundamental part of South; in Postgres, if you don't do it, some triggers might not be run yet, and in MySQL there's some other wackiness than temporarily escapes me, but it is also mad.

I should make it more clear in the docs/tutorial, but yes, you MUST separate the two, period. Making them work together would involve detecting the changes and then committing the transaction at that point (if we even have them), and you then lose having the whole migration in a transaction, at which point you may as well make it two.

I know it's annoying having them like that sometimes, but I think it's worth the result.

On a side note, you should be able to have one migration to create both the GIS and normal columns, and then another one to do data. I use GeoDjango? and South all the time, so it must be possible!

Note: See TracTickets for help on using tickets.