feat(guest): guest checkout without login (Swish + QR) #17

Open
hermes wants to merge 4 commits from feature/guest-checkout into master
Showing only changes of commit afe70125f1 - Show all commits

View file

@ -1,24 +1,25 @@
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
-- Allows orders without a registered user (guest checkout).
-- Users can place and pay for letters without creating an account.
--
-- user_id: previously NOT NULL drop the constraint so guest orders
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
-- user_id: previously NOT NULL - drop the constraint so guest orders
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
-- can be created without a registered user. The FK stays in
-- place (NULL user_id is FK-legal).
-- guest_email: contact address for the guest. Used to send the magic
-- link that lets them revisit their order status.
-- guest_token: opaque UUID v4 the only credential a guest has. Acts
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
-- guest_token: opaque UUID v4 - the only credential a guest has. Acts
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
-- as their session token for order lookup + payment confirm.
ALTER TABLE orders ALTER COLUMN user_id DROP NOT NULL;
ALTER TABLE orders ADD COLUMN guest_email VARCHAR(255);
ALTER TABLE orders ADD COLUMN guest_token UUID;
-- Partial unique index: only enforce uniqueness on non-NULL tokens.
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
-- Multiple NULLs allowed — existing user-owned orders have no token,
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
-- and that's fine.
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
-- Unique index on guest_token. Both H2 (tests/dev) and PostgreSQL (prod)
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
-- treat NULLs as distinct in a UNIQUE index, so user-owned orders (which
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
-- have a NULL token) never collide, while non-NULL guest tokens are
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
-- enforced unique. A plain index is used instead of a partial
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
-- (WHERE guest_token IS NOT NULL) index because H2 does not support
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
-- partial indexes, and the plain form preserves the intended semantics.
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
CREATE UNIQUE INDEX idx_orders_guest_token
ON orders(guest_token)
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
WHERE guest_token IS NOT NULL;
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
ON orders(guest_token);
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
CREATE INDEX idx_orders_guest_email
ON orders(guest_email)
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
WHERE guest_email IS NOT NULL;
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
ON orders(guest_email);
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.
Review

🟡 Missing DB-level orphan guard. The Order Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only onCreate() enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions:

ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest
    CHECK ((user_id IS NULL) <> (guest_token IS NULL));
🟡 **Missing DB-level orphan guard.** The `Order` Javadoc asserts "Either userId or guestToken is set; never both, never neither" — but only `onCreate()` enforces this in Java. A stray INSERT (admin tooling, future script) can violate it. Suggest adding after the column additions: ```sql ALTER TABLE orders ADD CONSTRAINT chk_user_or_guest CHECK ((user_id IS NULL) <> (guest_token IS NULL)); ```
Review

🔵 Unused index. idx_orders_guest_email is created but findByGuestEmail was never added to OrderRepository (the PR body lists it, but only findByGuestToken is there), so there's no read path on guest_email yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.

🔵 **Unused index.** `idx_orders_guest_email` is created but `findByGuestEmail` was never added to `OrderRepository` (the PR body lists it, but only `findByGuestToken` is there), so there's no read path on `guest_email` yet. Either add the lookup now or defer the index until the email-link phase to avoid an unused schema object.