Store only notification id in the payload for lockable notifications #76
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes #67
Currently for the updated django entity that has an associated TriggerChannel the notification payload is sent via postgres
NOTIFY
and it contains the old and the new serialized entity states. In the listener the payload that is sent via postgres channel is used only to find the appropriateNotification
record from the DB (by comparing the payload text) and then the payload is retrieved from the database record and is actually used.This sending of the complete payload is suboptimal:
old
andnew
records are sent that size is rather even smaller (<4k) for updates.NOTIFY
message) and then back to pg server (as a query parameter) and yet another time as a query result.This MR implements sending only the notification ID in the postgres notification for the
TriggerChannel
that has a persistent notifications enabled.This implementation keeps the listener backward compatible as in it can still process old notifications sent with a complete payload. That compatiblity should be removed in the followup versions.