Open le-jeu opened 2 years ago
Describe the bug On update, assignments that are already synced before are dropped by the server.
To Reproduce Steps to reproduce the behavior:
Related lines https://github.com/wasabee-project/Wasabee-Server/blob/76a7f79135ee33e7c20dca34e14066b2934c3a9c/model/database.go#L59
CREATE TABLE assignments ( opID char(40) NOT NULL, taskID char(40) NOT NULL, gid char(21) NOT NULL, KEY opID (opID), KEY gid (gid), CONSTRAINT fk_assignments_gid FOREIGN KEY (gid) REFERENCES agent (gid) ON DELETE CASCADE, CONSTRAINT fk_assignments_opid FOREIGN KEY (opID) REFERENCES operation (ID) ON DELETE CASCADE, KEY taskID (taskID,opID), CONSTRAINT fk_assignments_taskid FOREIGN KEY (taskID,opID) REFERENCES task (ID, opID) ON DELETE CASCADE );
https://github.com/wasabee-project/Wasabee-Server/blob/76a7f79135ee33e7c20dca34e14066b2934c3a9c/model/markers.go#L118
I suspect we get the correct list here: https://github.com/wasabee-project/Wasabee-Server/blob/76a7f79135ee33e7c20dca34e14066b2934c3a9c/model/task.go#L200 so, already synced assignments are not "replaced", but the data is deleted following the cascade deletion due to the REPLACE INTO query.
REPLACE INTO
Describe the bug On update, assignments that are already synced before are dropped by the server.
To Reproduce Steps to reproduce the behavior:
Related lines https://github.com/wasabee-project/Wasabee-Server/blob/76a7f79135ee33e7c20dca34e14066b2934c3a9c/model/database.go#L59
https://github.com/wasabee-project/Wasabee-Server/blob/76a7f79135ee33e7c20dca34e14066b2934c3a9c/model/markers.go#L118
I suspect we get the correct list here: https://github.com/wasabee-project/Wasabee-Server/blob/76a7f79135ee33e7c20dca34e14066b2934c3a9c/model/task.go#L200 so, already synced assignments are not "replaced", but the data is deleted following the cascade deletion due to the
REPLACE INTO
query.