Laravel Custom Fields Laravel Package

Product Decisions This Supports

• Configurable data model / custom fields roadmap item. This package provides the dynamic-field layer (user-defined attributes on existing Eloquent models) that would otherwise be a multi-sprint EAV build. It directly supports decisions like "can tenants add their own fields to records without us shipping a migration each time?" — the answer becomes yes, at the cost of a dependency.
• Build vs buy on metadata infrastructure. Custom fields are undifferentiated heavy lifting: storage, validation, filtering, indexing, concurrency. Buying this off means the team spends its roadmap capacity on the differentiated product surface instead. v1.0.1 strengthens that case by showing the maintainer is fixing the sharp edges (filter validation, write races) rather than leaving them to consumers.
• Search, segmentation, and reporting correctness. The number / boolean / contains filter fixes matter for any feature where users filter records by custom values. Silent type coercion (true matching 1) is the kind of bug that surfaces as "our segment count is wrong" in a customer escalation. Stricter filters (400 on invalid input) make filtering semantics a contract we can test against rather than a source of quiet data-quality bugs.
• Concurrency-safe writes for "first value wins" fields. The savepoint/upsert fix supports product behaviours that depend on a unique custom value per entity/host — first-touch attribution, lead-source capture, deduplicated form submissions. Previously, two simultaneous requests produced a 500-class UniqueConstraintViolationException; now the later write wins deterministically, matching sequential behaviour. That is a decision to allow concurrent writes on these fields without app-level locking or a queue.
• Use cases to prioritise: multi-tenant SaaS with per-tenant custom attributes, CRM/contact records, form builders, internal admin tooling, any product where an admin defines fields rather than an engineer.
• Release-management decision: v1.0.1 is a patch with no migration and no config change — a routine composer update is low-risk, but the stricter number filter is a user-visible behaviour change (previously accepted values now return 400). Worth a check on API clients and a dashboard on 400 rates post-deploy.

When to Consider This Package

Adopt when:

• The application is Laravel and the need is genuinely user-defined fields on existing models, not a handful of known optional columns (which are cheaper as real columns).
• Field definitions change at runtime — per tenant, per workspace, per record type — so migrations cannot keep up.
• Volumes are moderate and queries are record-centric (fetch a record with its fields, filter lists), not heavy analytical aggregation across custom fields.
• The team accepts EAV-style trade-offs: less obvious indexing, joins that need care, and validation rules living in configuration.
• You want filtering and validation handled for you rather than reimplemented per project.
• You need deterministic behaviour under concurrent writes to the same field.

Look elsewhere when:

• Custom fields must be first-class citizens in reporting/warehouse queries or need bespoke indexes and constraints per field.
• Scale is very high on writes to the same field/entity, where a database-level upsert in application code still needs load testing.
• The data model is stable and known up front — plain columns and migrations are simpler and faster.
• The stack is not Laravel/PHP, or the org requires a vendor with support SLAs.
• You need features the package does not claim: cross-field computed values, complex permissioning per field, versioned schema history. Those remain our build.

How to Pitch It (Stakeholders)

For executives: This is a small, focused Laravel dependency that lets customers configure their own fields on records instead of filing tickets for schema changes. It converts a recurring engineering cost into a one-off integration, and the 1.0.1 patch shows the maintainer is actively hardening it — two real defects (a numeric filter that silently matched the wrong rows, and a race condition that produced server errors on simultaneous writes) are fixed with no migration and no configuration change. Upgrade is a one-line Composer update with near-zero operational risk; the only thing to watch is that malformed numeric filter input now returns a 400 instead of quietly returning incorrect results, which is the behaviour we want but should be verified against any external API consumers.

For engineering: v1.0.1 tightens filter input validation (true/false no longer coerced into numeric filters; both throw InvalidFilterValueException → 400, while boolean filters are untouched), and wraps the unique-value insert in a savepoint so a losing concurrent insert becomes an update — last write wins, consistent with serial execution. No migration, no config change. Verify our clients don't send booleans to number filters, add a 400-rate monitor after deploy, and treat "later write wins" as the documented contract for these fields rather than adding our own locking.