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 pg>crdb case, I noticed if the original mutation is to update the pk of a row, replicator will actually insert a new row on target, rather than updating the existing one.
E.g. with employee_id the PK of the employees table,
UPDATE employees
SET employee_id =20-- New unique IDWHERE employee_name ='Bob Smith';
which results in the following in the source db:
defaultdb=# SELECT * FROM employees;
employee_id | employee_name | department
-------------+---------------+------------1 | Alice Johnson | HR
3 | Charlie Brown | IT
4 | David Wilson | Marketing
5 | Eva Davis | Sales
20 | Bob Smith | Finance
but on target:
root@localhost:26258/defaultdb>SELECT*FROM employees;
employee_id | employee_name | department
--------------+---------------+-------------1 | Alice Johnson | HR
2 | Bob Smith | Finance
3 | Charlie Brown | IT
4 | David Wilson | Marketing
5 | Eva Davis | Sales
20 | Bob Smith | Finance
It means the UPSERT happened with employee_id=20 in the where clause, rather than employee_id=2.
The text was updated successfully, but these errors were encountered:
For pg>crdb case, I noticed if the original mutation is to update the pk of a row, replicator will actually insert a new row on target, rather than updating the existing one.
E.g. with
employee_id
the PK of theemployees
table,which results in the following in the source db:
but on target:
It means the UPSERT happened with
employee_id=20
in the where clause, rather thanemployee_id=2
.The text was updated successfully, but these errors were encountered: