- Issue created by @djdevin
- πΊπΈUnited States djdevin Philadelphia
Added a test that illustrates the problem.
- πΊπΈUnited States djdevin Philadelphia
Thinking about how we could solve this.
I thought it would be possible to just associate both revisions with the workspace, so if one revision is disassociated the other one will still be there.
But, there's a unique index on the workspace_association table that prevents this:
PRIMARY KEY (`workspace`,`target_entity_type_id`,`target_entity_id`,`target_entity_id_string`)
It's strange that only one record per entity can exist here, but in a table like node_revision, multiple revisions can be associated with a workspace. Maybe we should update the index (and the code) to work off of the revision instead.
Another option is to update deleteAssociations() to either delete associations or update them to the most recent workspaced revision. But, that's probably confusing without renaming deleteAssociations to updateOrDeleteAssociations...