[SD-1670] Fix Paragraph data loss caused by unsafe MTK revision cleanup.#422
Open
MdNadimHossain wants to merge 1 commit into6.xfrom
Open
Conversation
|
Do we have an idea about increase in size for one of the bigger sites like |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
JIRA
https://digital-vic.atlassian.net/browse/SD-1670
Motivation
The current MTK cleanup rules for Paragraph revision tables were incorrectly removing revision records using the condition:
revision_id IN (SELECT revision_id FROM paragraphs_item)This logic assumes that only the latest (default) Paragraph revision is required. However, in Drupal, nodes reference Paragraphs using target_revision_id, meaning published nodes can depend on non-default (older) paragraph revisions.
As a result, the cleanup process was deleting revision data that is still actively referenced by nodes, causing Paragraph components to disappear from published content.
Changes
Removed unsafe MTK cleanup rules targeting:
paragraphs_item_revisionparagraphs_item_revision_field_dataparagraph_revision__*paragraph_r__*Paragraph Revision Bloat
To confirm why our previous MTK where clauses were "hollowing out" pages, I performed a database trace on a standard Landing Page.
The Test: Edit the Page Title only. Do not touch the Paragraph components.
The Node is currently at revision 1922, and its attached Paragraph is at revision 7069.
Check Node Revision
$ drush sql-query "SELECT nid, vid, title FROM node_field_data WHERE nid = 1171;" 1171 | 1922 | test paragraph versionCheck Paragraph Revision
$ drush sql-query "SELECT field_landing_page_component_target_id AS id, field_landing_page_component_target_revision_id AS rev FROM node_revision__field_landing_page_component WHERE entity_id = 1171;" 4347 | 7069Even though the Paragraph content was not changed, saving the Node triggered a new revision for the Paragraph automatically.
Check Node Revision (Increments to 1923)
$ drush sql-query "SELECT nid, vid, title FROM node_field_data WHERE nid = 1171;" 1171 | 1923 | test paragraph version weCheck Paragraph Revision (A new rev 7070 is created!)
$ drush sql-query "SELECT field_landing_page_component_target_id AS id, field_landing_page_component_target_revision_id AS rev FROM node_revision__field_landing_page_component WHERE entity_id = 1171;" 4347 | 7069 4347 | 7070 <-- NEW REVISIONTesting
Build image with
docker build -t test -f images/foo/Dockerfileand run withdocker run --rm -it test