You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For MySQL and PostgreSQL we have logic which detects CDC update events which modify the collection key of a document and translate that update into a paired delete of the old collection key and insert of the new row-state.
For SQL Server this logic is usually not necessary, because the source database already represents updates which modify the primary key of a table as a paired deletion and insert in the CDC change tables. Except, the collection key is not necessarily the same as the source database primary key, it just usually is because that's what we discover and make easy for users to set up automatically.
In the rare edge case where the user has explicitly set their collection key to something different from the source table's primary key, the behavior of SQL Server will be inconsistent with how MySQL or PostgreSQL captures handle the analogous scenario.
Fixing this would basically just require the same "compare preimage row key and postimage row key" logic that MySQL/PostgreSQL have, except that as of today SQL Server doesn't capture or even process update row preimages. So tackling this issue will require first addressing #2223 and then copying over the appropriate "encode row keys representing the preimage and postimage, then compare them" logic.
We have no plans to do this today, I'm just filing an issue so we have the context if this ever becomes necessary.
The text was updated successfully, but these errors were encountered:
For MySQL and PostgreSQL we have logic which detects CDC update events which modify the collection key of a document and translate that update into a paired delete of the old collection key and insert of the new row-state.
For SQL Server this logic is usually not necessary, because the source database already represents updates which modify the primary key of a table as a paired deletion and insert in the CDC change tables. Except, the collection key is not necessarily the same as the source database primary key, it just usually is because that's what we discover and make easy for users to set up automatically.
In the rare edge case where the user has explicitly set their collection key to something different from the source table's primary key, the behavior of SQL Server will be inconsistent with how MySQL or PostgreSQL captures handle the analogous scenario.
Fixing this would basically just require the same "compare preimage row key and postimage row key" logic that MySQL/PostgreSQL have, except that as of today SQL Server doesn't capture or even process update row preimages. So tackling this issue will require first addressing #2223 and then copying over the appropriate "encode row keys representing the preimage and postimage, then compare them" logic.
We have no plans to do this today, I'm just filing an issue so we have the context if this ever becomes necessary.
The text was updated successfully, but these errors were encountered: