Skip to content

Enforce NOT NULL constraint on notification_status#4908

Open
DilwoarH wants to merge 2 commits into
add-ft-service-stats-db-updates-1from
add-ft-service-stats-db-updates-2
Open

Enforce NOT NULL constraint on notification_status#4908
DilwoarH wants to merge 2 commits into
add-ft-service-stats-db-updates-1from
add-ft-service-stats-db-updates-2

Conversation

@DilwoarH

@DilwoarH DilwoarH commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

What

Enforce NOT NULL constraint on notification_status

Why

Without NOT NULL - we cannot create an index for notification_status column

@DilwoarH DilwoarH force-pushed the add-ft-service-stats-db-updates-2 branch from 8fce946 to e9e818f Compare July 2, 2026 15:08
@DilwoarH DilwoarH force-pushed the add-ft-service-stats-db-updates-1 branch 2 times, most recently from 81f9491 to 661c1ca Compare July 7, 2026 09:20
)
op.execute("ALTER TABLE notifications ALTER COLUMN notification_status SET NOT NULL;")

with op.get_context().autocommit_block():

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Notifications table only handles INSERT and UPDATE operations, PostgreSQL’s default replica identity already includes all required columns (template_id, notification_status, created_at) in the wal2json stream using our existing id primary key.
The DELETE operations are for archiving notifications to notification_history where notification_status counts must remain unchanged, so our aggregator can simply ignore all delete logs.
I think in this case we can skip this migration and it also saves write overhead on notifications table.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants