- Shipped
- August 25, 2026 at 6:14 PM UTC
- Author
- Kamo
- Commit
- 8ed40d7
Hibernate writes CHECK (col >= 0 AND col <= N) over an @Enumerated(ORDINAL) column at CREATE TABLE, where N is the highest ordinal that existed that day, and ddl-auto: update never revisits it. The day someone appends an enum value, every insert carrying the new ordinal is rejected — and because the failing statement is usually inside a @Transactional method, the rollback removes the evidence and the feature simply does nothing. Two of these were already full and already breaking things, found while checking whether the EHR could reuse the document manager rather than build a second one: - The five ImageAssocType checks allow 0-13. The enum reached ordinal 15 some time ago. PICTURE_FRAME and SYSTEM_BUG_SCREENSHOT therefore cannot have a folder, a doc type, a stacking order, an assoc config or a binder TODAY. Nothing reports it; the row just never appears. - img_dats_server_mime_check allows 0-35 and ImageMimeType had exactly 36 values — one new mime type away from rejecting every upload of that type. A second, wider constraint (check_server_mime, 0-99) already sat on the same column, so the narrow one was pure liability: the tighter check always wins. img_dats_age_req_typeid_check was likewise exactly full at nine values against 0-8. Dropped rather than widened, per the standing rule. Widening buys exactly one more enum value and then reproduces the same failure, with a migration in between that everyone will believe fixed it. The range enforces nothing worth having either: the application maps these columns through the enum both ways, so an out-of-range value cannot originate from the application, and one written outside it is a bug the check converts into a silent failure instead of an error someone sees.