Datavalidatorbundle Laravel Package

Product Decisions This Supports

• Database integrity as a first-class quality gate. The bundle validates constraint definitions (including foreign keys) against your actual schema. This supports decisions like “do we ship schema changes this sprint?” and “can we enforce referential integrity in the DB instead of application code?”
• CI/CD investment and shift-left strategy. The improved validation command — with verbose output showing constraint count, per-constraint names, wall time, and peak memory — makes it a credible pre-deploy check. Supports decisions on whether to add a schema-validation job to the pipeline versus relying on runtime errors found in staging/production.
• Build vs. buy for schema tooling. The 1.0.0-ALPHA2 release adds config-parameter and tagged-service constraint definitions, i.e. no YAML file required. This lowers the integration cost meaningfully and shifts the “build a bespoke validator” option toward “adopt and configure.”
• Operability and developer-experience roadmap. Graceful interruption (CTRL-C / SIGTERM / SIGINT) plus timing/memory telemetry signals a tool intended for interactive and long-running use. Supports prioritizing DX work on internal tooling and standardizing how long-running console commands behave across the platform.
• Configuration-as-code standardization. Moving away from mandatory YAML toward container config and tagged services aligns with the modern PHP/Symfony idiom, and is a data point for a broader decision to retire file-based config surfaces in our own services.
• Dry-run safety. The corrected FK constraint naming in dry-run mode supports decisions about making schema changes rehearsable — letting teams preview constraint effects before applying migrations.
• Use cases unlocked: pre-merge schema validation, migration review, auditing inherited/legacy schemas, catching drift between ORM mappings and real database constraints, and enforcing naming conventions on FKs.

When to Consider This Package

Adopt when:

• You rely on a relational database and care about foreign-key and constraint correctness, especially across teams where migrations are frequent and schema ownership is diffuse.
• You want schema validation in CI that fails fast and produces actionable, per-constraint output.
• You are on Symfony and can define constraints via container config parameters or tagged services — the new path removes the previous YAML-file friction and is the recommended route.
• You need dry-run/preview capability before applying constraint changes.
• Predictable console behavior matters: graceful signal handling means interrupted runs won't leave partial state or orphaned processes in CI or local dev.
• You are evaluating a 1.0 line and can tolerate pre-GA stability.

Look elsewhere when:

• You are on Laravel. This is a Symfony bundle (Symfony config parameters, tagged services, Symfony Validator-style API). Laravel’s container, config system, and validation story differ; expect to write adapter/shim work. Treat this as “conceptual fit, integration cost non-trivial” unless a Laravel-native equivalent is unavailable — in which case budget an explicit spike before committing. Alternatively, use it in a sidecar/service context that is not Laravel-coupled.
• The alpha designation is a blocker. 1.0.0-ALPHA2 means API churn and an explicit refactor of the exception hierarchy is already in flight. Production-critical paths should wait for beta/stable or accept a maintenance burden.
• You have no foreign-key constraints to speak of (e.g., document stores, or schemas deliberately constraint-free for sharding reasons).
• You need rich policy/reporting features rather than pass/fail validation.
• A mature schema-diff or migration tool in your stack already covers this overlap and you don't want a second opinion in the pipeline.

Risk notes to carry into adoption: this release intentionally changes the exception API (“common base for all exceptions; make API more similar to the Symfony Validator Component”). Any code currently catching specific exceptions, or asserting on dry-run constraint names, must be reviewed before upgrading. The FK-naming fix in dry-run is a behavior change, not just a cosmetic one — snapshot/expected-output tests may shift.

How to Pitch It (Stakeholders)

For executives (one paragraph): We are tracking a small but genuinely useful database-integrity tool at its first 1.0 alpha. The release makes it cheaper to wire up and much easier to operate: you can now define constraints through standard application configuration instead of maintaining a separate YAML file, the validation command can be stopped cleanly without leaving things half-done, and its verbose output tells you exactly what was checked and how long it took. Two bugs were fixed, including one where dry-run mode mislabelled foreign-key constraints — the kind of defect that erodes trust in a dry-run preview. Our recommendation is to pilot it in CI as a schema check rather than betting a critical release on it: it is still alpha, and this release deliberately reshuffles its error-handling API. Net: low cost to try, real upside in catching broken foreign keys before customers do, and no commitment until it reaches a stable release.

For engineering (summary): New constraint-definition routes — Symfony config parameter or tagged services — remove the YAML file as a required dependency; prefer tagged services for composability and testability. Verbose mode now reports constraint count, per-constraint names, elapsed time, and peak memory, which makes it viable as a CI job with actionable failures. Graceful SIGINT/SIGTERM handling means the command is safe to cancel in pipelines and locally. Two fixes: dry-run now emits correct FK constraint names (regression risk for any golden-output tests), and invalid constraint definitions now raise appropriate exceptions. Refactor introduces a shared exception base class and aligns the API with Symfony Validator — this is the upgrade hazard: audit all catch blocks and assertion strings. Caveat for our stack: this is a Symfony bundle, not Laravel-native; the container/config integration does not map directly to Laravel's, so treat adoption as requiring an integration spike or isolate it from the Laravel application. Target: trial on a non-critical service, pin the alpha, and revisit at beta/stable.