Skip to content
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

Closed
cbj4074 opened this issue Jan 26, 2021 · 1 comment

Comments

@cbj4074
Copy link
Contributor

cbj4074 commented Jan 26, 2021

  • Laravel Version: 8.24.0
  • PHP Version: 7.4.11
  • Database Driver & Version: PostgreSQL 12.4

Description:

Currently, Laravel's artisan migrate:fresh command fails after running artisan 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 is public. In any other scenario, exceptions occur.

Steps To Reproduce:

  1. When the connection's search_path contains only one schema, and it is anything other than the default value, public, attempting to run php artisan migrate:fresh after running schema:dump fails (the sole schema is homestead in this example):
  The command "PGPASSWORD=$LARAVEL_LOAD_PASSWORD pg_restore --no-owner --no-acl --host=$LARAVEL_LOAD_HOST --port=$LARAVEL_LOAD_PORT --username=$LARAVEL_LOAD_USER --dbname=$LARAVEL_LOAD_DATABASE $LARAVEL_LOAD_PATH" failed.

Exit Code: 1(General error)

Working directory: /home/vagrant/code/laravel

Output:
================


Error Output:
================
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 3; 2615 2200 SCHEMA homestead postgres
pg_restore: error: could not execute query: ERROR:  schema "homestead" already exists
Command was: CREATE SCHEMA homestead;

(and there are actually 15 additional errors that are ignored on restore, of a similar nature)

  1. Similarly, when the database contains more than one schema (regardless of those specified in the connection's search_path), attempting to run php artisan migrate:fresh fails after running artisan 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.

cbj4074 added a commit to cbj4074/framework that referenced this issue Jan 26, 2021
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
@cbj4074
Copy link
Contributor Author

cbj4074 commented Jan 26, 2021

It seems that pg_dump does not include a CREATE SCHEMA ... statement for public, but it does for any other schema name. Consequently, pg_restore reports the following error:

pg_restore: error: could not execute query: ERROR:  schema "homestead" already exists

This is really more of a warning than an error, and pg_restore keeps moving and restores all of the structures and data (where applicable) successfully. However, the Artisan command bails-out with an exception because the pg_restore exit code is 1.

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.

cbj4074 added a commit to cbj4074/framework that referenced this issue Jan 26, 2021
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
taylorotwell pushed a commit that referenced this issue Jan 27, 2021
…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
taylorotwell pushed a commit to illuminate/database that referenced this issue Jan 27, 2021
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants