Closed emmiegit closed 7 years ago
Since all three tables are essentially the same, we could also just make a single table called mentions
where the type of mention is an enum, and the mention_id
column is just generic.
have you considered storing the mentions as a http://docs.sqlalchemy.org/en/latest/dialects/postgresql.html#sqlalchemy.dialects.postgresql.ARRAY (https://www.postgresql.org/docs/current/static/arrays.html)? they're not going to be foreign keys anyway and the unique constraint could go away too this way
otherwise, since we again can't use a foreign key we should just have 1 table with an enum (and a comment explaining why we can't foreign key)
I thought about using an ARRAY
, but I see a downside in not being able to query it as easily. (To be honest, I'm not really sure how you even query members of arrays). Like for instance, I want to see how many times user 123 was mentioned in messages sent in channel 456. If they're separate rows, that's fairly easy.
in that case, I'm definitely in favor of an enum approach. the main downside to an enum for what to reference is you can't foreignkey the reference itself, but we don't have that problem so...
This PR creates a simple new table:
mentions.
It tracks mentions made in messages as they are both received by event and when crawling, and specifies what kind of mention it was (channel, user, or role).The mentioned ID field is purposely not a foreign key, since it is perfectly legitimate for a message to mention an invalid ID.