Add Builder::hasView('view_name') to check for existence of views #23145
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.
Sometimes it is quite convenient to check for the existence of something before actually executing code in a migration. We already may do that in our migrations for tables like so
As there is no counterpart that works for views (consistently across all supported DBMS) at the moment, this PR introduces a new function called
Builder::hasView($viewName)which does exactly the same asBuilder::hasTable($tableName)but for views. In some database grammars it just uses the query ofcompileTableExists()as fallback, but for SQL Server and SQLite it introduces a new query.Table prefix
In the current implementation, a design decision has been made by me which utilizes the existing
$this->connection->getTablePrefix()also for views. I'm not really sure if this makes sense as there are no methods on the schema builder which allow us to create views fluently yet. Therefore views may follow some different naming conventions which we are not yet aware of. I would suggest a change in this regard when going down the route to implement schema builder methods for view creation, though. Or maybe the introduction of such methods would solve this issue anyway as the normal table prefix could be used also for views.Tested code base
The code has not yet been tested and I'm happy to receive reviews and feedback from the CI.
Why views anyway?
Because we need them for third-party systems and we like to maintain them with our existing code base.