The Order entity Javadoc states "Either userId or guestToken is set;
never both, never neither" but only the @PrePersist lifecycle callback
enforced this in Java. A stray INSERT (admin tooling, manual SQL) could
violate it silently — creating an order with neither set (invisible to
both JWT and guest lookup paths) or both set (ambiguous ownership).
Changes:
- V13 Flyway migration adds a CHECK constraint on the orders table:
CHECK ((user_id IS NULL) <> (guest_token IS NULL))
This evaluates TRUE when exactly one column is NULL (the other is
set), and FALSE when both are NULL or both are set.
- Standard SQL CHECK constraint, supported by both H2 (tests/dev) and
PostgreSQL (prod).
Verified:
- Flyway migration check passes (V13 is next available version)
- ./gradlew :backend:test — BUILD SUCCESSFUL (all tests pass)
- H2 accepts the constraint at Flyway migration time
Closes #23
|
||
|---|---|---|
| .. | ||
| src | ||
| .gitattributes | ||
| .gitignore | ||
| build.gradle | ||
| gradlew.bat | ||