Active Record Laravel Package

Technical Evaluation

Scope correction — architecture fit. The release notes describe yiisoft/active-record 1.1.0, the Yii3 Active Record ORM. This is not a Laravel package: there is no service provider, no illuminate/database integration, and no Eloquent driver. If the programme standard is Laravel, this is out-of-stack and should be evaluated only if we have a Yii3 service, a legacy Yii2 estate, or a deliberate framework-agnostic PHP component strategy. Within a Yii3 application, fit is native: ActiveRecord, ActiveQuery, relations, and — as of #576/#577 — default configuration for the yiisoft/config plugin, which removes bootstrap boilerplate and is the main adoption-friction reduction in this release.

Integration feasibility. Low effort inside Yii3: a composer bump plus existing DI wiring. Effectively non-viable inside Laravel, where it would mean running a second ORM alongside Eloquent or writing a bridge; the query builder, relation semantics, dirty tracking and lifecycle hooks all diverge.

Technical risk. Semver-wise this is a minor release with no declared breaking changes, but several items are behavioural:

• #575 removes the empty-string check in AbstractActiveRecord::markPropertyChanged(). Assigning '' may now mark a property dirty, producing extra UPDATEs and changing isChanged semantics. Highest-risk item; test explicitly.
• #567 "properties with hooks" alters when hooks fire on property writes — subtle for models relying on attribute hooks.
• #561/#562 change upsert conflict precedence and which values win on update. Any downstream logic that depended on the old behaviour will silently change write outcomes.
• #550 relation queries are now created by the related class rather than the primary model — a correctness fix that can change generated SQL, table aliases, and inherited scope overrides.
• #558 changes SoftDelete behaviour with a custom date provider.
• #571 performance optimisation of ActiveRecord::get() is low risk but invalidates query-count baselines.
• #564 widens a documented param type (array<string|Closure> → array<string|callable(ActiveQueryInterface):void); source-compatible for closures, but static-analysis baselines may shift.

Key questions. Is the target application Laravel or Yii3 — the brief says Laravel, the artefact says Yii, and this must be resolved before further spend. Do we own a Yii3 service or is this part of a Yii2→Yii3 migration? Who owns the upsert call sites, and do we have conflict-precedence tests? Does any code rely on empty-string assignment not being flagged as a change? Are we on yiisoft/config, and do we want the new defaults?

Integration Approach

Stack fit. Native to Yii3 (yiisoft/active-record + Di + yiisoft/config). Not a Laravel dependency; adopting it in a Laravel product means committing to a second ORM or a bespoke bridge, which I would not recommend for greenfield Laravel work. If the goal is a portable domain layer, note the AR implementation is tightly coupled to Yii's DI and query interfaces, so portability is limited.

Migration path. From an earlier 1.x: composer update, regenerate the static-analysis baseline, no schema migrations implied by this release. From Yii2 ActiveRecord: a per-model port (attributes/rules/scenarios replaced, ActiveQuery API changes, behaviours replaced by hooks or listeners) — substantial, not a lift-and-shift. From Eloquent: a rewrite, not a migration.

Compatibility. Requires PHP 8.x and compatible yiisoft/db / yiisoft/definitions constraints; verify transitive pins before bumping. The #564 change is docblock-level but will surface new findings if static analysis gates CI. No data backfills are implied.

Sequencing.

1. Confirm the stack decision (Laravel vs Yii3) — this is the gate; stop here if Laravel is fixed.
2. Bump on a non-production branch; run unit and integration suites plus static analysis.
3. Add targeted tests for empty-string dirty tracking, upsert precedence, soft delete with custom date, relation class resolution, and property hooks.
4. Remove local workarounds superseded by #550/#558/#561/#562/#567.
5. Canary in staging with query logging on; then production.
6. Adopt the yiisoft/config defaults (#576/#577) as a separate, easily revertable change.

Operational Impact

Maintenance. Small, actively maintained Yii core package with a regular patch/minor cadence. Budget one routine bump per quarter plus upkeep of tests around dirty tracking and upsert semantics. The new config-plugin defaults reduce hand-maintained bootstrap configuration.

Support. Upstream is community/maintainer-driven on GitHub with no commercial SLA. Internal ownership must be named — realistically one backend engineer with Yii familiarity. If the team is Laravel-centric, bus factor is the dominant risk, because Eloquent knowledge does not transfer.

Scaling. Nothing in 1.1.0 is scaling-relevant; the get() optimisation is a modest CPU/latency win, not a capacity change. ActiveRecord-style ORMs move N+1 risk into application code, so keep query-count budgets in CI. Expect the #550 relation fix to alter some generated SQL plans — re-check slow-query logs after rollout.

Failure modes. Silent extra UPDATEs or missed change detection from #575; incorrect values written on conflict if upsert precedence assumptions were baked into downstream logic (#561/#562); SQL or alias mismatches in tests and raw fragments relying on old relation-class behaviour (#550); soft-delete timestamp regressions with custom date providers (#558); CI failures from the #564 signature change. Each is detectable with existing suites plus the targeted cases above, and none are silent permanently if query logging and CI gates are in place.

Ramp-up. For a Laravel engineer, one to two weeks to productivity on Yii3 AR and roughly a month to confidence on relations, dirty tracking and hooks. This release introduces no new concepts — it is a stabilisation release — so ramp-up cost is unchanged.