general
Maintainers & Projects
Who maintains this project?
A many-to-many between people and projects, read from either side.
Memberships are stored once, as edge items keyed by person then project. An inverted index swaps the keys, so 'a person's projects' reads the base table and 'a project's maintainers' reads the index, from the very same edges, with nothing duplicated.
The model
Membership
An edge: a person maintains a project, in a role.
- pk
- PERSON#<personId>
- sk
- PROJECT#<projectId>
Attributes: personId (S), projectId (S), role (S)
Access patterns
- QueryProjects a person maintains
List the projects a person maintains.
- Query · GSI1Maintainers of a project
List the people who maintain a project.
Design notes
One edge, two directionswhy
Each membership is a single item carrying both key pairs: PK/SK by person, GSI1PK/GSI1SK by project. The base table answers 'a person's projects' and the inverted index answers 'a project's maintainers'.
Inverting the keyshow
The index swaps the two: its partition key is the edge's project, its sort key the edge's person. Reading the relationship from the other end is the same query against a different index.
Taught in the course
- A different key for a different question - A secondary index re-keys your items so you can Query them on a new axis.
- Traverse a relationship both ways - An index that swaps the partition and sort keys reads the same edges from the other side.
List the projects a person maintains.
Choose an access pattern above, or build your own request. See what comes back and what it costs.
Write transactions, streams, tags and TTL are among the operations this browser build leaves out. dynoxide's native build has them.