In this issue, a first approach is made to clean said table.
Regarding the problem reported by @raphaeltbm and confirmed by @stewest on #66 we have also been able to replicate it.
The problem is that in the delete hook the entity is being deleted and not the translation due, among other things, to the problem with data duplication exposed in
https://www.drupal.org/project/paragraphs_asymmetric_translation_widgets... →
.
With the following image that shows data from the paragraphs_item_field_data table, we thoroughly explain the possible cases:
Yellow: Existing pre-migration paragraphs (original EN, DE and PT-PT translations)
Red: Once the migration process has been executed.
Green: Added a new translation of an existing node.
Blue: Added a new paragraph
The problem, as they indicated, is that if we delete a translation of the old ones (de, pt-pt) all its references are eliminated, including the original node.
For example, if we want to delete DE, in the delete hook it collects the following nodes: 8,9,10,67,68,69, 73,74,75 and deletes the entire entity by doing paragraph->delete().
As a first approximation and until the problem of duplicates is fixed, we can differentiate two cases: if it is a new translation where the language of the paragraph and the langcode of the entity match, we can eliminate the entire entity (red case). In any other case and whenever a translation exists, we will eliminate the translation of the paragraph (yellow, green, blue).
Regarding the previous commit...
Using this functionality in our project we have encountered a problem that could appear in other developments.
Our case:
We have a type of content in which we have a paragraph with different fields. Some of them are translatable but some others were not marked as such, for example a field_image. Before applying paragraph async, both the original node and the translations have that field_image, obviously. The problem was that when we applied the patch the translations lost that image (it may seem logical since it is not marked as translatable) but we were interested in keeping it. We could have developed a hook that updated all the nodes by making those fields translatable, saving the node and then applying the patch.
It may be interesting that in this type of cases and in the duplication process, said old content information is not lost and in the content migration those empty fields can be filled with the fields of the original node if it has them.
It has been committed to the MR and if you find it interesting we will keep it. If not, and it seems to you that it may be a case specific to a specific project, we will remove it.
chinataun → changed the visibility of the branch 2992777-implement-a-migration to active.
chinataun → changed the visibility of the branch 2992777-implement-a-migration to hidden.