chore(electric,client): Create new protocol op to represent a compensation #639
Conversation
VAX-1335 Create new protocol op to represent a compensation
Compensation requests are currently handled by a special SatOpUpdate message with empty |
magnetised
force-pushed
the
garry/vax-1335-create-new-protocol-op-to-represent-a-compensation
branch
from
9ac057b
to
be69b14
Compare
For permissions etc we need to always have the `OLD` values available, so for clarity don't send out SatOpUpdate with no old_data values
magnetised
force-pushed
the
garry/vax-1335-create-new-protocol-op-to-represent-a-compensation
branch
from
6216733
to
439a7cd
Compare
.changeset/itchy-carrots-invite.md
Outdated
| @@ -0,0 +1,6 @@ | |||
| --- | |||
| "@core/electric": patch | |||
There was a problem hiding this comment.
That's a minor on both, since you're introducing a cross-cutting feature that makes new clients incompatible with old server.s
There was a problem hiding this comment.
wasn't sure how we handled the version change now there's no version in the handshake or the protocol
There was a problem hiding this comment.
There is, it's just a bit hidden. It's sent in HTTP headers in WebSocket upgrade request.
| @@ -167,7 +166,7 @@ function generateCompensationTriggers(table: Table): Statement[] { | |||
| 1 == (SELECT value from _electric_meta WHERE key == 'compensations') | |||
| BEGIN | |||
| INSERT INTO _electric_oplog (namespace, tablename, optype, primaryKey, newRow, oldRow, timestamp) | |||
| SELECT '${fkTableNamespace}', '${fkTableName}', 'UPDATE', json_object(${joinedFkPKs}), json_object(${joinedFkPKs}), NULL, NULL | |||
| SELECT '${fkTableNamespace}', '${fkTableName}', 'COMPENSATION', json_object(${joinedFkPKs}), json_object(${joinedFkPKs}), NULL, NULL | |||
There was a problem hiding this comment.
do we need to handle client updates (i.e. reapply these triggers)?
There was a problem hiding this comment.
yes we would, good point. off the top of your head, is there a mechanism in place to trigger (😉 ) the re-creation of the triggers?
There was a problem hiding this comment.
@icehaunter looking at the client it seems that adding re-application of these triggers on boot is a fairly major change. are we comfortable with postponing that feature for the moment considering that this change is backwards compatible with existing trigger implementations?
There was a problem hiding this comment.
magnetised
deleted the
garry/vax-1335-create-new-protocol-op-to-represent-a-compensation
branch
For permissions etc we need to always have the
OLDvalues available, so for clarity don't send out SatOpUpdate with no old_data values