jocke/bilhej
1
0
Fork 0
Code Issues 6 Pull requests 6 Projects Releases 1 Packages Wiki Activity Actions

fix(db): add CHECK constraint for userId XOR guestToken invariant (#23) #26

Open
hermes wants to merge 1 commit from fix/order-user-guest-check-constraint into master
pull from: fix/order-user-guest-check-constraint
merge into: jocke:master
Conversation 0 Commits 1 Files changed 1 +17
1 changed files with 17 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
backend/src/main/resources/db/migration/V13__add_user_guest_check_constraint.sql Normal file
View file

@ -0,0 +1,17 @@
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
-- Enforce the Order entity invariant at the database level: exactly one of
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
-- (user_id, guest_token) must be set — never both, never neither.
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
--
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
-- The Order Javadoc states "Either userId or guestToken is set; never both,
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
-- never neither", but previously only the @PrePersist lifecycle callback
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
-- enforced this in Java. A stray INSERT (admin tooling, manual SQL) could
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
-- violate it silently.
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
--
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
-- The CHECK expression (user_id IS NULL) <> (guest_token IS NULL) evaluates:
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
-- TRUE when exactly one column is NULL (the other is set) — allowed
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
-- FALSE when both are NULL or both are set — rejected
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
--
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
-- Standard SQL CHECK constraint, supported by both H2 (tests/dev) and
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
-- PostgreSQL (prod).
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
ALTER TABLE orders
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
ADD CONSTRAINT chk_user_or_guest
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.
CHECK ((user_id IS NULL) <> (guest_token IS NULL));
hermes commented 2026-07-18 11:37:21 +00:00
Review
Copy link

💡 Suggestion (non-blocking): worth a @DataJpaTest that asserts this constraint rejects invalid rows — persist an Order with both userId and guestToken set, expecting a DataIntegrityViolationException referencing chk_user_or_guest. The @PrePersist in Order.onCreate() already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.

💡 Suggestion (non-blocking): worth a `@DataJpaTest` that asserts this constraint rejects invalid rows — persist an Order with both `userId` and `guestToken` set, expecting a `DataIntegrityViolationException` referencing `chk_user_or_guest`. The `@PrePersist` in `Order.onCreate()` already prevents the neither-set case at the application layer, so the both-set rejection is the untested, highest-value path.