Weave Code
Model Laravel Package
orchestra/model
Orchestra Model provides a reusable base Eloquent model for Laravel and Orchestra Platform applications, offering common model conventions and helpers that simplify building consistent, maintainable database-backed features.
Model Component for Orchestra Platform
Frequently asked questions about Model
- What is orchestra/model and what does it add to Laravel's Eloquent Model?
- Orchestra Model is the base model layer of the Orchestra Platform. It extends Illuminate\Database\Eloquent\Model and layers on four capabilities: Validable (validation bound to the saving event), Searchable (request-driven query scoping), Metable (model metadata) and Presenter (presentation bootstrapping). It also ships base User and Role models, Orchestra-specific events and contracts. It is a reusable base class for consistent, maintainable database-backed features rather than a standalone utility library.
- How do I install orchestra/model with Composer?
- Install it with composer require orchestra/model, then swap your domain models to extend Orchestra\Model\Model instead of Laravel's base model. The mechanical install is short, but the real gate is the compatibility matrix: confirm a published release line exists for your target Laravel and PHP versions before you start. Also check that the package resolves cleanly alongside your existing test harness.
- Which Laravel and PHP versions does orchestra/model support?
- Orchestra components track Laravel majors on separate release lines, so support depends on which line you install. The only concrete currency signal available in the evaluation is the changelog entry showing v6.0.0 as support for Laravel Framework v8. Before adopting, verify whether a release line exists for your target Laravel and PHP versions, and check when it last shipped.
- Do my models have to extend Orchestra\Model\Model to use the package?
- Yes. Adoption means your domain models extend Orchestra\Model\Model rather than Illuminate\Database\Eloquent\Model, which places the decision at the root of your domain layer. That is the hardest place in a Laravel codebase to reverse, so the choice is effectively binary. If you are not fully committed, extract the traits you need into App\Models\Concerns instead.
- Can I use orchestra/model outside an Orchestra Platform application?
- It is technically installable in any Laravel app, but it is architecturally the base layer of the Orchestra Platform rather than a standalone library. For a conventional Laravel application, none of the four traits justifies a third-party base class because each is reproducible in-house in tens to low hundreds of lines with full control retained. The default for a greenfield Laravel product is to use Illuminate\Database\Eloquent\Model directly.
- What do the Validable, Searchable, Metable and Presenter traits actually do?
- Validable binds validation to the saving event so invalid models fail before persistence. Searchable applies request-driven query scoping, letting you filter model queries from request input. Metable adds model metadata storage, and Presenter bootstraps presentation logic for your models. Together they cover common conventions, but each one changes model semantics subtly through magic such as save-time events and casting.
- What are the alternatives to orchestra/model for validation and searchable models?
- Write the traits yourself under App\Models\Concerns and keep Laravel's base model as the parent. Validation on save, request-driven query scoping and simple metadata are each a few dozen to a few hundred lines of code you fully control. The evaluation explicitly recommends reimplementing the two or three traits you actually need, because the opportunity signal here is a build-vs-adopt prompt rather than adoption evidence.
- How do I test models built on orchestra/model?
- Testing adds a second dependency: orchestra/testbench, which carries its own constraints and must resolve alongside your existing harness. These conflicts usually surface late, after models are already ported, and they break CI rather than production. Validate the testbench resolution in the same pass as the base install so you do not discover the mismatch mid-migration.
- Is orchestra/model actively maintained and safe to use in production?
- The evaluation flags high abandonment risk: it is a single-maintainer, low-visibility package with zero dependents, meaning there is no community canary and breakage reaches you first. Upgrade block risk is also high, because a base model cannot be casually patched around mid-upgrade, and if the release line stalls at Laravel 8 it becomes a hard ceiling on your modernization roadmap. Behavioral drift is a medium risk since base classes that add magic can change semantics subtly across versions.
- How hard is it to migrate away from orchestra/model, and how do I limit lock-in?
- Exit cost scales linearly with the number of models extending the base class, and that is the primary cost variable you control. Adopt only if you are committing to Orchestra Platform broadly or a short spike proves it saves materially more than reimplementation. Otherwise, keep the dependency out and own the traits internally, and confirm the license permits an internal fork if upstream stalls before you commit.
Weaver
How can I help you explore Laravel packages today?