-
Notifications
You must be signed in to change notification settings - Fork 11k
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
"artisan migrate:fresh" fails after running "artisan schema:dump" in all but the simplest/default scenario #36054
Comments
laravel#36054 was fixed in a previous commit, but appears to have been lost during subsequent edits in laravel@7be50a5 . This commit restores the changes made in laravel@502e75b . Fixes laravel#36054
It seems that
This is really more of a warning than an error, and And, in fact, upon further investigation, this was actually fixed in 502e75b , but the switches were later removed (inadvertently?) during subsequent edits in 7be50a5 . I've re-added the switches in #36046 , which again resolves the issues arising in both scenarios noted in the initial report. |
laravel#36054 was fixed in a previous commit, but appears to have been lost during subsequent edits in laravel@7be50a5 . This commit restores the changes made in laravel@502e75b . Fixes laravel#36054
…ple schemata (#36046) * Eliminate the need for search_path logic The PostgreSQL search_path logic that this commit removes was added with the intention of enabling support for a schema named anything other than "public". While the theory was sound, the implementation didn't take into account the behavior in databases in which *multiple* schemas exist. In multi-schema databases, the list of tables for which data should not be dumped was incorrect, leading to unexpected behavior. This revised approach takes advantage of PostgreSQL's support for pattern-based object references when specifying the list of tables for which data should not be dumped, and eliminates the need to perform complex search_path parsing altogether. The attendant Pull Request documentation explains how this technique works in detail. * Re-implement pg_restore fix that was reverted #36054 was fixed in a previous commit, but appears to have been lost during subsequent edits in 7be50a5 . This commit restores the changes made in 502e75b . Fixes #36054 * Fix PostgreSQL object reference pattern quoting While not required in a psql interactive terminal, this pattern requires outer double-quotes to function as intended when passed as a CLI argument. While simple in this specific instance, pattern quoting can grow complicated (depending on the pattern), but is well explained in the PostgreSQL manual: https://www.postgresql.org/docs/current/app-psql.html#APP-PSQL-PATTERNS
…ple schemata (#36046) * Eliminate the need for search_path logic The PostgreSQL search_path logic that this commit removes was added with the intention of enabling support for a schema named anything other than "public". While the theory was sound, the implementation didn't take into account the behavior in databases in which *multiple* schemas exist. In multi-schema databases, the list of tables for which data should not be dumped was incorrect, leading to unexpected behavior. This revised approach takes advantage of PostgreSQL's support for pattern-based object references when specifying the list of tables for which data should not be dumped, and eliminates the need to perform complex search_path parsing altogether. The attendant Pull Request documentation explains how this technique works in detail. * Re-implement pg_restore fix that was reverted laravel/framework#36054 was fixed in a previous commit, but appears to have been lost during subsequent edits in laravel/framework@7be50a5 . This commit restores the changes made in laravel/framework@502e75b . Fixes #36054 * Fix PostgreSQL object reference pattern quoting While not required in a psql interactive terminal, this pattern requires outer double-quotes to function as intended when passed as a CLI argument. While simple in this specific instance, pattern quoting can grow complicated (depending on the pattern), but is well explained in the PostgreSQL manual: https://www.postgresql.org/docs/current/app-psql.html#APP-PSQL-PATTERNS
Description:
Currently, Laravel's
artisan migrate:fresh
command fails after runningartisan schema:dump
in all but the simplest of scenarios — that is, this process works correctly only when the database contains exactly one schema and its name ispublic
. In any other scenario, exceptions occur.Steps To Reproduce:
search_path
contains only one schema, and it is anything other than the default value,public
, attempting to runphp artisan migrate:fresh
after runningschema:dump
fails (the sole schema ishomestead
in this example):(and there are actually 15 additional errors that are ignored on restore, of a similar nature)
search_path
), attempting to runphp artisan migrate:fresh
fails after runningartisan schema:dump
, with similar exceptions (relation already exists, multiple primary keys not allowed, etc.).I'm investigating possible solutions and will post an update or open a PR when ready.
The text was updated successfully, but these errors were encountered: