-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SQLx can't find applied migration due to collision between schema and username in search_path #3523
Comments
More specifically, all migrations up through the one that creates the schema will succeed, but at that point the migration machinery will begin to behave incorrectly. This is because the Postgres driver references the Prior to the creation of the new schema, any unqualified object reference like For some reason, this change doesn't take effect immediately, so the first run of migrations will work correctly, but subsequent ones will fail. I'm not actually sure why this works at all the first time around; I think it may be because the insert to It's also possible that the change doesn't take effect until after the transaction is committed, which we wouldn't see when running just one migration. Regardless, the next time migrations are run with a new connection, the change in resolution applies. The migration machinery checks if Since the migrations machinery sees an empty table ( Since the DDL in OP's case uses Failing fast is probably the best case scenario here, as otherwise the migration machinery could end up making duplicate, potentially destructive changes. Potential SolutionsI'm wary of changing the default behavior, because I don't want to screw over anyone who might have run into this and just worked around it. If we just changed the queries to reference Being able to explicitly rename or relocate However, I think we can, and should, detect when this might be happening and bail out before doing the wrong thing. Amongst a bunch of other very interesting functions (including some that might help improve the null inference in the macros, like
This is essentially the same as We can query this in sqlx/sqlx-postgres/src/migrate.rs Line 114 in 293c55c
We'd then check if
Bikeshedding: should we bail if a table named We could also be smarter in generating the error if we actually check if the contents of any of the After #3383, if |
Bug Description
When a user lets call them
roster
applies a migration that creates a schema equal to the username,roster
, only the first migration will be applied correctly.The second migration attempt SQLx will not be able to find the original migration table
public._sqlx_migrations
and attempts to apply the migration again. A new table is created under the schema and usernameroster
but applying the migration actually fails as it has already been applied.After some troubleshooting with @abonander it turns out that postgreSQL's search_path is
"$user", public
.Due to the collision between the username and schema, the schema
roster
will be chosen to search for the migration table. As the schema did not exist before the first migration, the first migration ran successful.https://www.postgresql.org/docs/current/ddl-schemas.html#DDL-SCHEMAS-PATH
Minimal Reproduction
A small code snippet or a link to a Github repo or Gist, with instructions on reproducing the bug.
roster
(can be anything but be consistent).Info
rustc --version
: rustc 1.80.1 (3f5fd8dd4 2024-08-06)The text was updated successfully, but these errors were encountered: