Laravel Bits Laravel Package

Product Decisions This Supports

• Bulk per-row updates as a product capability. The updateMany macro lets a single statement assign different values to different rows (order statuses, per-tenant limits, price tiers, re-synced inventory). That underwrites admin bulk-edit screens, import/reconciliation jobs, and webhook-driven state fan-out without N round-trips or hand-written CASE WHEN SQL.
• Database engine choice / migration roadmap. Through v1.5.3, updateMany emitted MySQL backticks and unquoted identifiers, so it was effectively MySQL-only. v1.5.4 makes it grammar-aware, which means a PostgreSQL migration (or a multi-engine support commitment) is no longer blocked by this dependency. If Postgres is on the roadmap, this release is the minimum viable version — do not ship on earlier ones.
• Build vs. buy for bulk-write plumbing. This replaces in-house CASE-expression builders, chunked update loops, and ad-hoc raw SQL. Scope is narrow (query-builder macros plus an AsBoolean cast), so the buy decision is low-cost and reversible.
• Multi-tenant / prefixed-schema products. Honouring the connection's table prefix means the macro is usable in deployments that isolate tenants by prefix rather than separate databases — previously that would have generated invalid SQL.
• Schema-compatibility decisions. Quoting via the connection grammar means columns named after reserved words (order, group, key) are now safe. This widens adoption to legacy or third-party schemas we don't fully control.
• Data-integrity risk posture. The missing ELSE branch was not cosmetic: records absent from a given set had columns overwritten with NULL, or the statement failed outright on non-nullable integer/timestamp columns. Any prior use of multi-set updateMany should be treated as potentially corrupting and audited.

When to Consider This Package

Consider it when:

• You need heterogeneous values across rows in one UPDATE — bulk editing, importers, sync jobs, pricing/entitlement recalculation. If every row gets the same value, whereIn(...)->update([...]) is the right tool and this package adds nothing.
• You must support both MySQL and PostgreSQL (or expect to), and want one code path rather than engine-specific branches. Pin >= 1.5.4; earlier versions are MySQL-only in practice.
• You run prefixed tables or maintain schemas with reserved-word column names.
• You are comfortable extending Laravel's query builder via macros — an accepted, low-ceremony pattern, but it does mean the behaviour lives outside the framework's own test surface.
• You need the AsBoolean cast alongside the query macros; the multi-engine test suite now exercises it too, which is a modest maturity signal for that piece.

Look elsewhere when:

• You need true upsert semantics (insert-or-update). Use the framework's upsert(); this is an update-only macro.
• You need per-row audit trails, model events, or observers to fire. Bulk statements bypass Eloquent events — if compliance requires an event or history row per change, this is the wrong layer.
• Your batches are very large. A single CASE-based statement grows with the row count; confirm parameter/binding limits on your engine and plan to chunk. The release notes don't address statement-size limits.
• You require first-party, vendor-supported dependencies, or your team cannot absorb a small package's maintenance risk.
• Test coverage is a gating criterion and you cannot verify it. The new cross-engine tests only run when LARAVEL_BITS_TEST_PGSQL_URL / LARAVEL_BITS_TEST_MYSQL_URL are set. Confirm the maintainer's own CI sets them; if not, the "tested on Postgres and MySQL" claim describes capability, not a guarantee. The grammar-compilation checks (no server required) are the more reliable signal and do run unconditionally.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small Laravel add-on that enables efficient bulk updates — changing many records to different values in a single database statement. Its value is mundane but real: it removes a recurring category of hand-written SQL from our codebase and cuts database round-trips on bulk operations. The latest release fixes genuine correctness defects that made it unusable outside MySQL, and in one case could silently null out data. Net position: low cost, low lock-in, worth a timeboxed trial; not a strategic bet.

For engineering: v1.5.4 is a correctness release, not a feature release. Three fixes matter: grammar-based identifier quoting (Postgres no longer rejects the statement, and reserved-word columns work everywhere), an ELSE branch per CASE (prevents NULL overwrite and untyped-binding failures on Postgres integer/timestamp columns, and fixes multi-set updates that touch disjoint row sets), and table-prefix awareness. Cross-engine test coverage was added but is conditional on environment variables — we should verify it actually runs upstream and add our own integration test against our target engine, our prefixed schema, and at least one reserved-word column before depending on it.

Recommendation: Adopt behind a one-sprint spike. Pin ^1.5.4 and treat anything earlier as unsafe for Postgres. Audit any existing call sites that pass multiple sets to updateMany for rows that may have been set to NULL. Wrap usage in a thin internal helper so the dependency stays swappable, and confirm chunking strategy for large batches, since statement size scales with row count.