We have a use case where we are using Deploy to send content from a master site to other microsites. Unlike a typical setup, the child sites are sometimes updated independently of the master resulting in some UUID logic getting mixed up. The most common issue is that a UUID for a node won't match up for the current version, but there is a revision that matches which causes everything to get mucked up.
Please review the patch I'm submitting as any comments are much appreciated. I've tried to add comments in the code explaining the whys.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | uuid-uuid_revision-records-2664752-6.patch | 3.82 KB | mrmikedewolf |
Comments
Comment #2
mrmikedewolf commentedComment #3
mrmikedewolf commentedRereolling due to logic mistake.
Comment #4
mrmikedewolf commentedRe-rolling to be more clean and logically sound.
Comment #5
mrmikedewolf commentedI made a mistake in setting UUID and VUUID to the values in the database. These need to be set to the values coming in from outside.
Corrected the patch.
Comment #6
mrmikedewolf commentedTurns out we need one more addition in order to pull this off.
File fields, oddly, go to greater lengths than any other field to try to preserve UID on themselves. No other field does this in any uuid_field_presave hooks.
This one odd eccentricity makes the logic in entity_property_uuid_to_id() nearly impossible to keep together.
I've removed any attempt of file fields to correct UID. Perhaps this should be re-implemented in an alternative way.