Description
I'm learning Loco with a pet project. I noticed that my latest migration wasn't generating the expected table, so I manually dropped my tables (including the migration table) and attempted to recreate them. I found that the tables were not being created when I ran cargo loco db migrate or cargo loco db reset.
What I ended up discovering is that the generate model is creating boilerplate code that was re-using a primary key index name. When migrate or reset ran, postgresql logged the message ERROR: relation "idx-refs-pk" already exists and aborts the transaction.
Because two migrations are attempting to use the same primary key name of idx-refs-pk, the second migration will fail silently, which seems to abort the entire transaction.
To Reproduce
# Create a fresh Saas project
loco new
# Create a "Movies" scaffold
cargo loco generate scaffold movies name:string^
# Create a many:many relationship, which creates a pkey of "idx-refs-pk"
cargo loco generate model --link movies_actors user:references movie:references
# Do the same thing, but for tv
cargo loco generate scaffold tvshows name:string^
# Create another many:many, but for tv shows. It also tries to use a pkey of "idx-refs-pk"
cargo loco generate model --link tvshows_actors user:references tvshow:references
Expected Behavior
A clear and concise description of what you expected to happen.
- The generated migration uses a unique primary key index name, like
idx-movies-actors-pk.
- When running
cargo loco db migrate or cargo loco db reset, if there is a failure to create, a clear error message is returned to the user.
Environment:
MacOS 14.2.1
Rust 1.75.0
Additional Context
I suspect that the migration is running within a single transaction, so the last migration causes the entire migration to fail, which is why dropping all tables and re-running the migration resulted in no tables being recreated.
demo.zip
Description
I'm learning Loco with a pet project. I noticed that my latest migration wasn't generating the expected table, so I manually dropped my tables (including the migration table) and attempted to recreate them. I found that the tables were not being created when I ran
cargo loco db migrateorcargo loco db reset.What I ended up discovering is that the
generate modelis creating boilerplate code that was re-using a primary key index name. Whenmigrateorresetran, postgresql logged the messageERROR: relation "idx-refs-pk" already existsand aborts the transaction.Because two migrations are attempting to use the same primary key name of
idx-refs-pk, the second migration will fail silently, which seems to abort the entire transaction.To Reproduce
Expected Behavior
A clear and concise description of what you expected to happen.
idx-movies-actors-pk.cargo loco db migrateorcargo loco db reset, if there is a failure to create, a clear error message is returned to the user.Environment:
MacOS 14.2.1
Rust 1.75.0
Additional Context
I suspect that the migration is running within a single transaction, so the last migration causes the entire migration to fail, which is why dropping all tables and re-running the migration resulted in no tables being recreated.
demo.zip