rorm: composite unique constraints
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Read the rorm model and migration documentation, then inspect services/mtg/src/models/deck/db.rs, the root Cargo.toml, and services/mtg/src/tests/collaborators.rs. First determine how rorm represents model constraints and generated migrations; the issue also depends on a rorm release that supports composite uniqueness. Done means generated migrations enforce unique (deck, account), the collaborator tests pass, and the uuid v3 feature is removed if unused.
Written by the indexing model from the issue text.
Description
rorm has no way to declare a unique constraint over more than one field, and adding one through RawSQL in a migration trips the warning in check-migrations.yaml.
Workaround in use: deck Collaborators (#155) derive their primary key from the pair, collaborator_key(deck, account) = Uuid::new_v3(&deck, account.as_bytes()) in services/mtg/src/models/deck/db.rs, so naming an Account twice on a deck collides on the primary key. This enabled uuid's v3 feature, which pulls md-5 0.10.6 into Cargo.lock next to the existing md-5 0.11.0.
What to build
- In rorm: a composite unique constraint on a model (e.g. a model-level attribute naming the fields), carried through the migration generator.
- Here, once a rorm release has it: give
DeckCollaboratorModela unique(deck, account)constraint, switch its primary key back to a random uuid (or keep the derived one, decide then), and drop thev3feature from the rootCargo.tomlif nothing else uses it.
Acceptance criteria
- rorm supports composite unique constraints, including generated migrations
-
DeckCollaboratorModeluses one; uniqueness per deck and Account is unchanged (tests inservices/mtg/src/tests/collaborators.rsstay green) - uuid
v3feature removed if unused
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 1
- Avg merge
- 10h 20m
- Merged PRs (30d)
- 36
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from myOmikron/code
-
needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
wayfinder:task
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
wayfinder:task
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
myOmikron/code#102 · 2 comments ·
Maintainers usually reply within 1 day
-
ready-for-agent
Difficulty 5/5 Over a week Newbie friendliness 18/100
Maintainers usually reply within 1 day
-
needs-triage
Difficulty 5/5 Over a week Newbie friendliness 25/100
Maintainers usually reply within 1 day
Similar issues
-
area:agent-view area:tui bug platform:macos
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
anthropics/claude-code#104558 ·
Maintainers usually reply within 1 day
-
updater
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
UniversityOfHelsinkiCS/oodikone#5141 ·
-
maintanance
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
inmanta/web-console#7606 ·
Maintainers usually reply within 1 day
-
bug skills
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
equinor/fusion-framework#5846 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 74/100