Opened 8 years ago
Last modified 6 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 , 8 years ago
| Component: | Migrations → GIS |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
comment:2 by , 8 years ago
comment:3 by , 6 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:5 by , 6 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.