- How do I create a SQL view in a Laravel migration?
- Use the createView macro on Laravel's schema Blueprint inside a normal migration, passing the view name and the SELECT statement that defines it. The package adds createView and dropView, plus createOrReplaceView and rename, so view DDL lives alongside table migrations. Install via Composer and run php artisan migrate as usual; no separate view-management command is required.
- Does staudenmeir/laravel-migration-views support Laravel 13?
- Version 1.12 is a compatibility-only release that adds Laravel 13 support with no API changes, deprecations, or breaking changes. Check the package constraint in Composer for the exact Laravel and PHP floor before planning an upgrade, because that constraint, not new package features, is the real gate. For teams already on the supported matrix, it is a low-cost checklist item.
- Which databases can I use with Laravel Migration Views?
- The package supports MySQL, PostgreSQL, SQLite, and SQL Server. That covers a realistic local, CI, and production matrix, but you should still confirm each environment uses the same engine or accept dialect differences. Views are a common place for SQLite tests and PostgreSQL production to diverge.
- Do I need to publish a config file for staudenmeir/laravel-migration-views?
- No config file is required. The service provider is auto-discovered, so Composer require is essentially the whole installation. You can prove it out with one migration file that creates a view and then rolls it back.
- Can I create or replace a view in a Laravel migration?
- Yes, the package provides a createOrReplaceView macro in addition to createView. Use it when a reporting read model or compatibility view changes and you want the migration to update the definition. Be deliberate about rollback behavior, because replacing a view does not automatically restore the previous definition unless your migration does.
- How do I rename or drop a database view in Laravel?
- The Blueprint macros include dropView and rename, so you can manage a view lifecycle in the same migration style as tables. Keep dependency order in mind when dropping views that other views or application queries rely on. Test rollback paths, since an orphaned view can shadow a table name and cause confusing failures later.
- Can Eloquent models use views created by this package?
- Yes. Once the view exists in the database, an Eloquent model can treat it like a table for reads, which is useful for reporting read models, denormalized export surfaces, and compatibility shims. Writes are a different matter: a view is generally read-only unless the database and view definition support updatable behavior. Keep view definitions versioned in migrations so models and consumers agree on the schema.
- How should I test Laravel migrations that create views across SQLite and PostgreSQL?
- Run the migration test suite against the same engine you use in production whenever view behavior matters, because view syntax and capabilities differ across MySQL, PostgreSQL, SQLite, and SQL Server. A SQLite-only test can pass while PostgreSQL fails on dialect or dependency details. At minimum, add a CI job that migrates from scratch and rolls back on the production engine.
- Does this package support PostgreSQL materialized views?
- The documented package description covers standard SQL views, not materialized views. Some assessment material references PostgreSQL materialized-view macros and manual REFRESH MATERIALIZED VIEW CONCURRENTLY, so treat that as unresolved until you verify the README and source for your version. If materialized views are in scope, you also need an owner and a refresh lifecycle, which is separate from creating a normal view.
- Is staudenmeir/laravel-migration-views safe for production and well maintained?
- It is a thin extension of Laravel's schema builder, so the release risk is low; the pattern risk is moderate and centers on view dependency ordering, CREATE/DROP VIEW permissions, rollback correctness, and schema dump/restore behavior. The package is a small, single-maintainer community project with zero dependents, which is a discoverability signal rather than a quality verdict but does mean no ecosystem pressure keeps it maintained. Apply your dependency support policy and test the failure paths before relying on it for business-critical reporting views.