- What is calebdw/laravel-sql-entities used for?
- It maps SQL query results to typed PHP entity classes inside a Laravel application, giving you attribute casting, relationships, and query integration without the overhead of full Eloquent models. Each PHP class carries attributes describing a SQL entity such as a view, function, or stored procedure, and the package registers and ships those entities through Laravel's migration and service-container conventions. It is aimed at raw SQL, legacy schemas, and read models where Eloquent does not fit cleanly.
- Which Laravel and PHP versions does laravel-sql-entities support?
- Confirm the declared support matrix against the package's composer.json and its CI matrix before adopting it, because the published compatibility gate is not something you should assume is complete. Version 1.1.1 specifically repairs Laravel 12 support after 1.1.0 shipped code that relied on a framework trait available only in Laravel 13. Laravel 13 should remain functional, and the PHP floor is governed by attribute and class-string usage, so check it against your runtime before rollout.
- How do I install calebdw/laravel-sql-entities with Composer?
- Install with composer require calebdw/laravel-sql-entities:^1.1.1 and add a conflict rule against 1.1.0 so a stale lockfile or transitive resolution cannot pull the broken release back in. After installing, publish any config or migration stubs the package provides and run your migrations as usual. Verify the service provider is registered and that your attribute-driven entity classes resolve before trusting the setup.
- Does laravel-sql-entities support attribute casting and relationships like Eloquent?
- Yes. The package provides attribute casting and relationship support on top of plain typed entity classes, so you get much of the ergonomics of Eloquent models while mapping from raw SQL results. The trade-off is that it is not a full ORM and does not attempt to replicate every Eloquent feature. Check the specific cast types and relationship kinds your read models need against the package docs.
- How do I define a SQL view, function, or stored procedure as an entity?
- You define a PHP class with attributes describing the SQL entity, and the package registers it and ships it through Laravel's migration pipeline. This treats schema as code, so views, functions, and procedures are versioned alongside the application rather than created through ad-hoc DDL. Confirm which entity types are covered and whether they are created and dropped through migrations or a separate artisan command before planning your rollout.
- Should I upgrade from 1.1.0 to 1.1.1, and what breaks on Laravel 12?
- Upgrade to 1.1.1 and pin it explicitly with a conflict against 1.1.0. On Laravel 12, version 1.1.0 relied on a framework trait that only exists in Laravel 13, so attribute reads failed silently: entities could be created with default names and options instead of failing loudly. Any environment already running 1.1.0 should be audited by re-running migrations in a disposable database and diffing the resulting DDL against your expectations.
- Does laravel-sql-entities work with multiple connections, schemas, and multi-tenant setups?
- Connection, schema, and multi-tenant handling are key questions to verify explicitly in the package config rather than assume. Entity resolution is string and class-name driven, so aliasing, class preloading, and per-tenant connection switching are the areas most likely to surprise you. Test a two-connection and two-schema scenario in a disposable database before committing to a multi-tenant design.
- How are inter-entity dependencies ordered, such as a view built on another view?
- Dependency ordering between entities, for example a view that selects from another view or a function used by a view, is something you should confirm against the package source and docs. Migration-driven entity creation usually means you control ordering yourself through migration sequence. If ordering is implicit, add an explicit test that builds the full dependency chain from scratch to catch gaps.
- Is laravel-sql-entities a replacement for Eloquent?
- No. It complements Eloquent and the rest of your schema tooling rather than replacing them, and it is a poor fit for teams that rely on ad-hoc DDL or an ORM-first migration style that cannot express views and functions. It suits Laravel teams already using migrations as the source of truth and comfortable with PHP 8 attributes. Think of it as a typed read-model layer for raw SQL, not a general persistence layer.
- Is laravel-sql-entities safe to use in production, and who maintains it?
- It is viable in production if you pin ^1.1.1, enforce your own CI matrix across the Laravel and PHP versions you actually deploy, and treat future minor bumps as requiring a full matrix run on your side. A Laravel-13-only symbol reached a tagged release and was caught by CI rather than a version gate, which points to release-process risk. The package is also single-maintainer, so keep a fork or vendor contingency plan, and track the vendored ReadsClassAttributes trait against upstream attribute-reading semantics since it can drift.