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
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