Opened 7 years ago
Last modified 5 years ago
#29058 assigned Bug
Adding 'null=True' to a PointField doesn't create working migration
Reported by: | Yaman Ozakin | Owned by: | Victor Munene |
---|---|---|---|
Component: | GIS | Version: | dev |
Severity: | Normal | Keywords: | geodjango, pointfield |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
before:
class House(models.Model): point = models.PointField()
after:
class House(models.Model): point = models.PointField(null=True)
migration:
class Migration(migrations.Migration): dependencies = [ ('myapp', '0001_initial'), ] operations = [ migrations.AlterField( model_name='house', name='point', field=django.contrib.gis.db.models.fields.PointField(null=True, srid=4326), ), ]
Traceback:
python manage.py migrate Operations to perform: Apply all migrations: admin, auth, contenttypes, myapp, sessions Running migrations: Applying myapp.0002_auto_20180125_1119...Traceback (most recent call last): File "manage.py", line 22, in <module> execute_from_command_line(sys.argv) File "/Users/Basia/yamyam/research/django/myenv/lib/python3.6/site-packages/django/core/management/__init__.py", line 364, in execute_from_command_line utility.execute() File "/Users/Basia/yamyam/research/django/myenv/lib/python3.6/site-packages/django/core/management/__init__.py", line 356, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/Users/Basia/yamyam/research/django/myenv/lib/python3.6/site-packages/django/core/management/base.py", line 283, in run_from_argv self.execute(*args, **cmd_options) File "/Users/Basia/yamyam/research/django/myenv/lib/python3.6/site-packages/django/core/management/base.py", line 330, in execute output = self.handle(*args, **options) File "/Users/Basia/yamyam/research/django/myenv/lib/python3.6/site-packages/django/core/management/commands/migrate.py", line 204, in handle fake_initial=fake_initial, File "/Users/Basia/yamyam/research/django/myenv/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 "/Users/Basia/yamyam/research/django/myenv/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 "/Users/Basia/yamyam/research/django/myenv/lib/python3.6/site-packages/django/db/migrations/executor.py", line 244, in apply_migration state = migration.apply(state, schema_editor) File "/Users/Basia/yamyam/research/django/myenv/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 "/Users/Basia/yamyam/research/django/myenv/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 "/Users/Basia/yamyam/research/django/myenv/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.House.point into myapp.House.point - they do not properly define db_type (are you using a badly-written custom field?)
Using Spatialite as backend engine.
Change History (5)
comment:1 by , 7 years ago
Component: | Migrations → GIS |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 7 years ago
comment:3 by , 5 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:5 by , 5 years ago
Patch needs improvement: | set |
---|---|
Version: | 1.11 → master |
Note:
See TracTickets
for help on using tickets.
This is actually more widespread problem with spatialite backend.
DB geometry field in spatialite backend is defined as None which causes any kind of migration, even just adding verbose name which doesn't change field type nor anything database related to cause error message.
All other spatial backends seem to return at least some kind of a db field type.