Nova Duplicate Field Laravel Package

Technical Evaluation

Architecture fit. v0.3.0 adds field-level ignore/override controls to the replication path. In Laravel terms this most plausibly lands as declarative model configuration (an except/override map consumed by the replication service) rather than raw SQL rewriting, which is the right layer: it keeps replication policy next to the model's schema knowledge and composes with existing Eloquent casting, connections, and queue workers. This is the single most requested capability for the common use cases — environment promotion (strip auto-increment IDs, timestamps, tenant IDs), PII exclusion, and value remapping across database connections.

Integration feasibility. If the package is already in the stack, adoption is configuration-only: no schema migration, no new infrastructure. The real effort is deciding the field policy, which is domain knowledge, not code. Because there is no prior assessment, baseline facts are unverified: supported Laravel/PHP matrix, DB driver coverage, test suite depth, maintainer bus factor, and whether replication runs inline or via queued jobs.

Technical risk.

• Semantics ambiguity (highest risk). "Ignore" can mean omit from the INSERT or write NULL/default. The first fails loudly against NOT NULL columns without defaults; the second silently corrupts data. This must be confirmed against source, not release notes.
• Pre-1.0 versioning. 0.3.0 is a minor bump, but under semver pre-1.0 minor releases may break. Treat as potentially breaking until the default no-op behavior is proven.
• Precedence vs. framework hooks. Unclear whether overrides apply before or after casts, mutators, model events, and upsert/updateOrCreate paths. Divergence here produces bugs that only appear on specific write paths.
• Security upside with a sharp edge. Field exclusion is the cleanest way to keep PII out of replicated targets — but it is opt-in per field, so a newly added sensitive column silently replicates until someone updates the policy.

Key questions. Does ignore drop the column or null it? Are overrides per-target-connection or global? Does it compose with bulk insert/upsert? Any change to default behavior when no ignore/override is configured? Test coverage added in #23? Is there a documented upgrade note for 0.2.x users?

Integration Approach

Stack fit. Standard Laravel: service provider registration, config/database.php connections, Eloquent models, optional queue workers (Horizon/Redis). Confirm PHP and Laravel version constraints in composer.json before committing; confirm the feature is driver-agnostic (MySQL/Postgres at minimum, SQLite for CI).

Migration path. Pin 0.3.0 on a feature branch, run the existing replication test suite plus a row-count and checksum diff between source and target. No data migration should be required for the feature itself, but any existing replication config gains new optional keys — verify the absence of those keys produces byte-identical behavior to 0.2.x.

Compatibility. Two checks gate promotion: (1) default no-op equivalence for current configs, and (2) no transitive dependency bumps that shift the framework version floor. Read the full CHANGELOG, not just the release headline — feature entries frequently ship with quiet behavioral fixes.

Sequencing.

1. Pin and install in dev; verify constraint resolution.
2. Establish the field policy matrix (below) before writing any config.
3. Apply ignore first for mechanical columns (PKs, timestamps, tenant IDs) — lowest judgment required.
4. Apply override second for environment-specific values (status flags, connection-scoped IDs).
5. Shadow-run alongside current replication; diff counts and per-table checksums.
6. Promote to staging, then production behind a flag if the package supports it.

Operational Impact

Maintenance. Small surface area, low ongoing cost — but pre-1.0 means quarterly version review and a willingness to read diffs rather than trust the version number. Assign a named owner for the field policy, distinct from the owner of the dependency version.

Support. Issue #23 indicates an active maintainer and a responsive backlog. Single-maintainer risk is unquantified here and should be assessed before production dependence; mitigate with a fork-and-patch contingency and a pinned version.

Scaling. Ignore lists are evaluated at config time — effectively free. If overrides are implemented as per-row callables, expect measurable per-row overhead on large batches; benchmark at target volume (100k+ rows) rather than assuming.

Failure modes.

• Loud: ignored NOT NULL column without a default → insert failure. Acceptable; caught in staging.
• Silent: schema change adds a sensitive column and no one updates the ignore list → PII reaches the target. This is the failure mode worth engineering against.
• Silent: override sets a value a downstream consumer depends on, diverging between environments.
• Mitigations: a schema-change checklist that requires a field-policy review on every migration, plus a periodic automated comparison of source/target sensitive-column values (expect zero non-null on target).

Ramp-up. Low for any Laravel developer — the API is declarative and reads naturally. The non-obvious cost is that which fields are environment-specific is tribal knowledge. Document a field policy matrix (table → column → ignore/override → rationale → owner) as the primary onboarding artifact; the package config then becomes a direct transcription of it, and the matrix survives a package swap.