- Shipped
- August 22, 2026 at 10:03 PM UTC
- Author
- Kamo
- Commit
- bceafd2
One row per Picture Frame widget a member has arranged on their launchpad. A table rather than a preference blob because the photos and videos in a frame are imaging rows carrying its id in assoc_object_id, and an association needs something durable to point at. A frame id living only inside a member's JSON preferences would be a foreign key to nothing: nothing could enforce that the frame still exists, and clearing a member's preferences would silently orphan every byte they had uploaded. settings is TEXT holding JSON on purpose. It is the frame's appearance — read whole to draw one pane, written whole on save, never queried into — so as columns every new bevel or grain the designer grows would be another DDL change landing here before the service that maps it, for a value no query will ever filter on. @Order(0) per the schema convention: once the shared-lib entity exists, any runner that loads a PictureFrame through JPA emits these columns in its SELECT, so a late-ordered migration would never be reached — an earlier runner would die on "relation picture_frames does not exist" and take the run down first. NOTE FOR DEPLOY: SecurityService runs hibernate ddl-auto: none, so this table does not appear on its own. This service must be RUN before the picture frame feature works.