Postgres uuid field in an earlier migration

Hi guys, I’m trying to deploy using docker to a postgres database but I’m getting the psycopg2.errors.CannotCoerce: cannot cast type bigint to uuid error.
Problem is the affected migration is 18 migrations ago so the “delete it, delete the field and then create a new field” solution I’ve seen elsewhere is a bit more complicated. Anyone got any suggestions how I can fix it?

Do you have a bit more context info? What are your actual changes, that create the bigint to uuid hassle? Did you change the pk type of a very old django project (pre 3.2) by any chance? Normally the fact, that the change is like 18 migrations in the past, should not impact you - django would just spool through them (unless there are already issues in former migrations you missed).

(Sidenote: There was a bug in the related field resolving in pre 3.2 versions, where uuid pks could get misinterpreted as ints.)

Hi jerch,
This is a project running on 4.2.1, I’m
The reason it hadn’t been caught earlier is that I have only just started Dockerizing the app to prep to move it to a production environment. Before this it had been running with a SQLite db for dev purposes.

The issue is that at migration 4 I changed the type of the ID field from the default int to UUID. When I try and build the Docker container I get the error I described at migration 4 since apparently Postgres can’t convert from int to uuid and thus won’t go any further in the migration chain.

This is the contents of the relevant migration:

# Generated by Django 3.2.8 on 2021-10-21 14:56

from django.db import migrations, models
import uuid

class Migration(migrations.Migration):

    dependencies = [
        ('car', '0003_car_colour'),

    operations = [
            field=models.UUIDField(default=uuid.uuid4, editable=False, primary_key=True, serialize=False),

And here is the traceback for the error I’m getting (the latest migration in this app is 022)

Traceback (most recent call last):
2023-06-08T09:01:24.860520100Z   File "/usr/local/lib/python3.9/site-packages/django/db/backends/", line 87, in _execute
2023-06-08T09:01:24.860945300Z     return self.cursor.execute(sql)
2023-06-08T09:01:24.860994900Z psycopg2.errors.CannotCoerce: cannot cast type bigint to uuid
2023-06-08T09:01:24.861004500Z LINE 1: ...TABLE "car_car" ALTER COLUMN "id" TYPE uuid USING "id"::uuid
2023-06-08T09:01:24.861009900Z                                                                  ^
2023-06-08T09:01:24.861114900Z The above exception was the direct cause of the following exception:
2023-06-08T09:01:24.861133400Z Traceback (most recent call last):
2023-06-08T09:01:24.861138500Z   File "/home/<myproject>/<myproject>/", line 22, in <module>
2023-06-08T09:01:24.861225500Z     main()
2023-06-08T09:01:24.861245500Z   File "/home/<myproject>/<myproject>/", line 18, in main
2023-06-08T09:01:24.861416600Z     execute_from_command_line(sys.argv)
2023-06-08T09:01:24.861465300Z   File "/usr/local/lib/python3.9/site-packages/django/core/management/", line 442, in execute_from_command_line
2023-06-08T09:01:24.861670400Z     utility.execute()
2023-06-08T09:01:24.861725000Z   File "/usr/local/lib/python3.9/site-packages/django/core/management/", line 436, in execute
2023-06-08T09:01:24.862037700Z     self.fetch_command(subcommand).run_from_argv(self.argv)
2023-06-08T09:01:24.862090900Z   File "/usr/local/lib/python3.9/site-packages/django/core/management/", line 412, in run_from_argv
2023-06-08T09:01:24.862317000Z     self.execute(*args, **cmd_options)
2023-06-08T09:01:24.862368700Z   File "/usr/local/lib/python3.9/site-packages/django/core/management/", line 458, in execute
2023-06-08T09:01:24.862647300Z     output = self.handle(*args, **options)
2023-06-08T09:01:24.862711100Z   File "/usr/local/lib/python3.9/site-packages/django/core/management/", line 106, in wrapper
2023-06-08T09:01:24.862723600Z     res = handle_func(*args, **kwargs)
2023-06-08T09:01:24.862759900Z   File "/usr/local/lib/python3.9/site-packages/django/core/management/commands/", line 356, in handle
2023-06-08T09:01:24.863065300Z     post_migrate_state = executor.migrate(
2023-06-08T09:01:24.863122000Z   File "/usr/local/lib/python3.9/site-packages/django/db/migrations/", line 135, in migrate
2023-06-08T09:01:24.863534700Z     state = self._migrate_all_forwards(
2023-06-08T09:01:24.863595000Z   File "/usr/local/lib/python3.9/site-packages/django/db/migrations/", line 167, in _migrate_all_forwards
2023-06-08T09:01:24.863689800Z     state = self.apply_migration(
2023-06-08T09:01:24.863747400Z   File "/usr/local/lib/python3.9/site-packages/django/db/migrations/", line 252, in apply_migration
2023-06-08T09:01:24.863985000Z     state = migration.apply(state, schema_editor)
2023-06-08T09:01:24.864040700Z   File "/usr/local/lib/python3.9/site-packages/django/db/migrations/", line 132, in apply
2023-06-08T09:01:24.864497700Z     operation.database_forwards(
2023-06-08T09:01:24.864552800Z   File "/usr/local/lib/python3.9/site-packages/django/db/migrations/operations/", line 235, in database_forwards
2023-06-08T09:01:24.865029900Z     schema_editor.alter_field(from_model, from_field, to_field)
2023-06-08T09:01:24.865076600Z   File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/", line 830, in alter_field
2023-06-08T09:01:24.865964300Z     self._alter_field(
2023-06-08T09:01:24.866016000Z   File "/usr/local/lib/python3.9/site-packages/django/db/backends/postgresql/", line 287, in _alter_field
2023-06-08T09:01:24.866474400Z     super()._alter_field(
2023-06-08T09:01:24.866517500Z   File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/", line 1055, in _alter_field
2023-06-08T09:01:24.866831700Z     self.execute(
2023-06-08T09:01:24.866877800Z   File "/usr/local/lib/python3.9/site-packages/django/db/backends/postgresql/", line 48, in execute
2023-06-08T09:01:24.866893300Z     return super().execute(sql, None)
2023-06-08T09:01:24.866903600Z   File "/usr/local/lib/python3.9/site-packages/django/db/backends/base/", line 201, in execute
2023-06-08T09:01:24.867102700Z     cursor.execute(sql, params)
2023-06-08T09:01:24.867155900Z   File "/usr/local/lib/python3.9/site-packages/django/db/backends/", line 67, in execute
2023-06-08T09:01:24.867211700Z     return self._execute_with_wrappers(
2023-06-08T09:01:24.867269600Z   File "/usr/local/lib/python3.9/site-packages/django/db/backends/", line 80, in _execute_with_wrappers
2023-06-08T09:01:24.867441700Z     return executor(sql, params, many, context)
2023-06-08T09:01:24.867503500Z   File "/usr/local/lib/python3.9/site-packages/django/db/backends/", line 89, in _execute
2023-06-08T09:01:24.867544300Z     return self.cursor.execute(sql, params)
2023-06-08T09:01:24.867560000Z   File "/usr/local/lib/python3.9/site-packages/django/db/", line 91, in __exit__
2023-06-08T09:01:24.868032100Z     raise dj_exc_value.with_traceback(traceback) from exc_value
2023-06-08T09:01:24.868079400Z   File "/usr/local/lib/python3.9/site-packages/django/db/backends/", line 87, in _execute
2023-06-08T09:01:24.868115800Z     return self.cursor.execute(sql)
2023-06-08T09:01:24.868128400Z django.db.utils.ProgrammingError: cannot cast type bigint to uuid
2023-06-08T09:01:24.868134600Z LINE 1: ...TABLE "car_car" ALTER COLUMN "id" TYPE uuid USING "id"::uuid
2023-06-08T09:01:24.868140400Z                                                                  ^
2023-06-08T09:01:24.956208500Z   Applying car.0004_alter_car_id...Collecting static files...

Hope this makes sense.

This sounds like your production target has no real-world data yet? If thats the case, you could either try sqashing the migrations on that model into just one initial (more friendly to all dev instances, but caution - needs to be applied on all dev instances before you can remove the old migration cascade), or go with a faked initial (more disruptive, would not be my first choice).

If there is no real-world data yet at all, well - delete all migrations, remove db files on dev instances, and startover from scratch (makemigrations → migrate, creates initial migrations with uuid field in the first place).

That’s correct, no real world data yet and I’m the only dev so the complete deletion and remake the migrations is probably the best option for simplicity (annoying but what can you do).

Just to check, the fact that the primary key is a UUID won’t inherently cause issues with Postgres? Also the new migration cascade will need to work with other models that may have a dependency on it, should I also redo those models or will it compensate?


Nope, thats just fine for postgres.

Yes - well a proper squash can deal with that, also a wipe + fresh initial would also handle it correctly.

Since you have no real data yet and you are the only dev, imho starting over from scratch for all your models is prolly the simplest way. Most annoying part for me would be the fact, that the VCS (idk if you use git etc) has still broken code in older commits for postgres, but again - not much to be done other than just fixing it at some point.

Sounds like a problem for another day.

Many thanks for your help jerch.