I think the aliases table would make more sense as a single source of truth for emails.
- 8Knot queries are more complicated because of needing to compare between the "primary" email and the aliases (having to get the email from two places
- this could potentially have performance benefits for 8knot to fix this
- we currently have no logic for which email is the "primary one" other than "whichever one happened first"
- this will probably greatly simplify augur collection process (find a new email, check if it exists already, if not insert it into the aliases table).
Data Migration
data migration for this DB change is simple since we allow duplicate aliases (i see some in our prod now) - we can just add an alias unconditionally for every current contributors primary address, and then delete the column for it in contributors (it is already foreign key referenced)
Note
Migrated from augurlabs/augur#3746
Originally opened by
@MoralCodeon 2026-03-02I think the aliases table would make more sense as a single source of truth for emails.
Data Migration
data migration for this DB change is simple since we allow duplicate aliases (i see some in our prod now) - we can just add an alias unconditionally for every current contributors primary address, and then delete the column for it in contributors (it is already foreign key referenced)