You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
orcargo 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. Whenmigrate
orreset
ran, postgresql logged the messageERROR: 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
Expected Behavior
A clear and concise description of what you expected to happen.
idx-movies-actors-pk
.cargo loco db migrate
orcargo 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
The text was updated successfully, but these errors were encountered: