Create ft_service_stats table#4910
Conversation
klssmith
left a comment
klssmith
left a comment
There was a problem hiding this comment.
Just making a note of the things we chatted about, one thing we could consider is to use a composite primary key, matching what we do with the existing ft tables, which means the ID column isn't necessary and it will automatically get a unique index.
We also don't want test notifications to show up on the dashboard, so unless we're specifically not writing test notifications to the new table, might need to add a column for key_type so we can filter these out
| sa.Column("template_id", postgresql.UUID(as_uuid=True), nullable=False), | ||
| sa.Column("notification_type", postgresql.ENUM(name="notification_type", create_type=False), nullable=False), | ||
| sa.Column("notification_status", sa.Text(), nullable=False), | ||
| sa.Column("date", sa.Date(), nullable=False, server_default=sa.text("CURRENT_DATE")), |
There was a problem hiding this comment.
If this is the date in BST, we probably don't want this default since it won't be in BST. It could help avoid confusion or misunderstandings to call the column bst_date too, like we do for ft_notification_status
DilwoarH
changed the title
ft_service_stats tableft_service_stats table
76fa3e5 to
6158044
Compare
DilwoarH
changed the title
ft_service_stats tableft_service_stats table
6158044 to
e156f46
Compare
This is needed to store daily stats from WAL logs
e156f46 to
45f3ed4
Compare
klssmith
left a comment
klssmith
left a comment
There was a problem hiding this comment.
The plan to not write test notifications to this table means we don't need to have a column for key_type, so this is fine to not have that
2 participants
What
Add migration to create
ft_service_statstable with relevant indexesWhy
We need the
ft_service_statstable to store the count of statuses