First party support for database views

[bilogic]

Several of my projects need to create and update VIEWS for computation purposes, and over time, I have become quite clear of the limitations in the framework currently.

Often, I'm told to just put it in a migration, but there are problems:

1. VIEWS must always run in order to keep up to date with the new migrations
   • migrations are tracked to run only once, so not suitable
2. A safe point in the lifecycle to run VIEWS is after the full DB schema is complete, i.e. at the end of all migrations
   • migrations filenames have a timestamp, so not suitable

In short, there are challenges in using migrations to create/update a VIEW.

It also does not make sense to create/update a VIEW in a seeder since it is dealing with the schema after all and also requires the developer to explicitly --seed when running artisan migrate every single time. Forgetting to do so will result in an incomplete schema.

My proposal is to introduce a new section at the end of artisan migrate and artisan migrate:fresh that runs every time. Think of it like an implicit seeder, but dealing with schema instead of data.

Happy to do a PR, but probably need to decide on the naming first, since views is also used to refer to blade views.

[sixtusagbo]

This is exactly the discussion I was about to create before I saw yours. I support this! I'm suggesting db views since there's already blade views.

[bilogic]

happy to know someone else in my same situation :)