mirror of
https://github.com/GSA/notifications-api.git
synced 2026-09-08 18:43:12 -04:00
4adab1afeb
This makes the assumption that we do not need NotificationHistory, we will need to ensure that for HighVolumeServices we do not recalculate the stats tables, either in the reporting_tasks nor in the commands. The strategy to migrate to using this code is still up for design. We will need to consider: - how to purge the data, safely, efficiently. - ensure we get the counts right for the stats table, the ft_notification_status table is particularly tricky, because as a notification moves from created -> sending -> delivered the row counts change for each status type. One idea is that we only write the `delivered`, `temporary-failure` and `permanent-failure` status into the table. This is not production ready but just a draft to get the conversation going. I also have an idea to stop returning "todays" notification data for HighVolumeServices on the dashboards/usages (except platform_admin) until this code is ready.
28 lines
864 B
Python
28 lines
864 B
Python
"""
|
|
|
|
Revision ID: 0319_high_volume_service
|
|
Revises: 0318_service_contact_list
|
|
Create Date: 2020-03-20 08:53:22.624516
|
|
|
|
"""
|
|
from alembic import op
|
|
import sqlalchemy as sa
|
|
from sqlalchemy.dialects import postgresql
|
|
|
|
revision = '0319_high_volume_service'
|
|
down_revision = '0318_service_contact_list'
|
|
|
|
|
|
def upgrade():
|
|
# ### commands auto generated by Alembic - please adjust! ###
|
|
op.create_table('high_volume_service',
|
|
sa.Column('service_id', postgresql.UUID(as_uuid=True), nullable=False),
|
|
sa.PrimaryKeyConstraint('service_id')
|
|
)
|
|
op.create_index(op.f('ix_high_volume_service_service_id'), 'high_volume_service', ['service_id'], unique=True)
|
|
|
|
|
|
def downgrade():
|
|
op.drop_index(op.f('ix_high_volume_service_service_id'), table_name='high_volume_service')
|
|
op.drop_table('high_volume_service')
|