Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
When moving an entity from one changeset to another, we first use cps_is_entity_in_changeset() to ensure that the entity does not exist in the destination changeset. Since cps_is_entity_in_changeset() uses cps_get_tracked_entities() which in turn does a query restricting the entities to published=0, it's possible that the entity does actually exist in the destination changeset, which then causes a SQL duplicate key exception when cps_move_changeset() is called and does a simple db_update() of the changeset id.
Proposed resolution
Add a new optional argument to cps_get_tracked_entities() to explicitly get all entities, and not just unpublished ones, and use this in cps_get_tracked_entities()
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | cps-in_changeset-3218341-6.patch | 1.92 KB | douggreen |
Comments
Comment #2
douggreen CreditAttribution: douggreen as a volunteer commentedPatch attached
Comment #3
douggreen CreditAttribution: douggreen as a volunteer commentedComment #4
douggreen CreditAttribution: douggreen as a volunteer commentedUpdated patch also moves the module_invoke_all of the cps_move_changeset hook inside the transaction.
Comment #5
douggreen CreditAttribution: douggreen as a volunteer commentedThis is just fixing a symptom of a problem (other than the transaction change, which might be related to the real problem). The root problem is that a cps_entity has a published=1 value when the changeset itself is not published.
Comment #7
douggreen CreditAttribution: douggreen as a volunteer commentedA minimal change was committed to see if that solves the problem first ... before doing the bigger change here.
Updated patch is attached.