-
Notifications
You must be signed in to change notification settings - Fork 11.4k
[9.x] Fix "artisan db:wipe" command does not drop tables in all schemas #41541
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
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a 9.x breaking change for the
$excludedTables
check on line 72. Existing apps with values inconfig('database.pgsql.dont_drop')
won't be schema-qualified with wrapping quotes. Even the hardcoded$excludedTables = ['spatial_ref_sys']
default value used by 99.9% of Laravel/Postgres apps will fail to be skipped.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great catch! Thank you! This is exactly why I said the following in the related Issue:
I'll work on a solution to this. Thanks again!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whenever it's convenient, please take a look at the new commit that I pushed. My hope is that it resolves the concern that you raise here.
Now, tables are excluded in a backwards-compatible way, so that all of the following table notations would be excluded:
This configuration produces the following
DROP
query in a stock Laravel installation in whichphp artisan migrate
has been run (andmigrations
is the only table we didn't exclude):So, in essence, the user can schema-qualify those
dont_drop
references if desired, and if not, the unqualified references will be treated just as they have been prior to this PR. That is to say, when a reference is unqualified, the table will not be dropped from any schema in which it exists.As a related aside, the the current logic around the
spatial_ref_sys
table that exists when thepostgis
extension is enabled seems a little odd to me.In essence, the logic is, "If the user has not specified tables to be excluded, then exclude
spatial_ref_sys
, else, exclude the specified tables (in which casespatial_ref_sys
will be dropped)."Is that necessarily the desired behavior? It seems all too easy to drop
spatial_ref_sys
without even realizing it's happening, merely by specifying some other, completely unrelated table(s) to be excluded. I suppose once the user realizes what's happening, they'll addspatial_ref_sys
to thedont_drop
array, too.The same is true of the
dropAllViews()
method. It'll drop the two views that are created forpostgis
(geography_columns
andgeometry_columns
):I don't know if any of this is of concern to anybody, I just figured I'd mention it while on the subject.