Laravel Sql Entities Laravel Package

Product Decisions This Supports

• Where stored DB objects live in the SDLC. This package lets views, functions, and stored procedures be defined as PHP classes with attribute-based configuration and shipped through Laravel's migration/deploy flow. That directly affects whether DB objects get code review, CI, and rollback like the rest of the app — or remain an out-of-band DBA task.
• Build vs. buy for schema-object management. The alternative is hand-written DB::statement() blocks in migrations (cheap, unversioned, copy-pasted) or a dedicated migration/provisioning tool. This package sits between them: Laravel-native, class-per-entity, but small and single-maintainer.
• Feasibility of a "database-as-code" roadmap item. If your backlog includes moving legacy views/procedures into version control, or formalizing reporting views, this is a credible enabling dependency for a spike.
• Platform upgrade sequencing. v1.1.1 exists specifically because the framework trait the package relied on is Laravel 13-only; the package now ships its own ReadsClassAttributes so attribute configuration works on Laravel 12. That makes "adopt on Laravel 12 now, upgrade to 13 later" a viable path instead of a forced coupled upgrade.
• Not supported by this release: no new features, no API surface changes, no deprecations. This is a compatibility/correctness fix, so it does not unlock new product scope — it removes a blocker and a CI-fragility risk.

When to Consider This Package

Consider it when:

• You are on Laravel 12 or 13 and want stored views/functions/procedures to be first-class, reviewable code artifacts rather than ad-hoc SQL.
• Your team is already fluent in Laravel migrations and would rather not introduce a separate schema-management toolchain.
• The set of DB objects is non-trivial (dozens of views/procedures), and drift between environments is a recurring source of incidents.
• You pin >= v1.1.1. v1.1.0's attribute configuration path was broken on Laravel 12; anything earlier than 1.1.1 should be treated as not-Laravel-12-compatible. This is a hard floor for adoption, not a nice-to-have.
• You are comfortable with a young, low-version (1.x), single-maintainer package for a piece of your deploy pipeline.

Look elsewhere when:

• You are not on Laravel, or your DB objects are owned by a DBA team with an existing migration/change-control process you cannot route through app deploys.
• Your stored procedures carry substantial business logic — attribute-driven PHP class definitions are a poor fit for large procedural bodies, and the tooling here won't give you the testing/debugging story that logic deserves.
• You need a vendor with SLAs, broad production adoption, or a security review trail. The bug fix itself (a framework trait being Laravel-13-only) is a signal of tight coupling to framework internals; expect this package to need a release around each major Laravel bump.
• Your database engine or object types fall outside what the package supports — verify against your actual view/function/procedure mix before committing.

How to Pitch It (Stakeholders)

For executives: A small, low-cost Laravel package that lets us manage database views and stored procedures as version-controlled code instead of manual DBA changes. The value is reduced environment drift and safer rollbacks on schema objects, not new customer-facing features. Cost of adoption is low; the main risk is dependency on a young, single-maintainer package, which we mitigate by pinning versions and keeping our own test coverage around generated SQL.

For engineering: v1.1.1 is a bug-fix release with two changes. First, it vendors ReadsClassAttributes into the package because the framework trait it depended on is Laravel 13-only — v1.1.0's attribute configuration was effectively broken on Laravel 12 and failing CI. Second, it removes a non-literal class-string passed to Collection::get(), which newer PHPStan rejects. Neither change alters the public API. Recommendation: treat v1.1.1 as the minimum usable version, pin it explicitly, and add a static-analysis gate in CI so future PHPStan-level breakage surfaces in our build rather than in a runtime path. Given the Laravel-13-only trait incident, budget for a compatibility review at each major framework upgrade.