One issue is that it is not very clear what the checkbox "Create field values for new fields in target content type" is actually doing.
In addition I discovered a problem when the option is enabled: When an entity is converted from one bundle to another, if there are multiple revisions, the revision__field tables do not get changed.
entity_type_revision__field_name table: You will see that the previous revisions still have the old bundle in their bundle column, and only the latest one (that was created by \Drupal\convert_bundles\ConvertBundles::addNewFields has the new bundle.A first step would be to clarify what the "Create field values for new fields in target content type" option is supposed to be doing.
Then we could work on a solution.
Depends on what the solution might be.
Depends on what the solution might be.
Depends on what the solution might be.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | delete-revisions-for-removable-fields--3271643-5.patch | 1.99 KB | efpapado |
Comments
Comment #2
el1_1el commentedSo I wasnt able to reproduce the issue on a revision field that existed on both content types. I tested text, boolean, list, entity reference, and entity reference revisions.
But I do see that fields in the old content type that are not in the new content type maintain the old bundle, which is expected because attaching a non existent field to an entity would cause an error. So I'm wondering if you are mapping field A on entity type A to field B on entity type B and then expecting all revisions for field A to be migrated to field B? If that is the case maybe add a patch to addNewFields function that does that.
If that is not the case, and you are mapping field A on entity type A to field A on entity type B and this is still happening to you, I have noticed some possible issues with caching that happens if you take some time to fill out the form and depending on your cache max settings in config/development/performance. If that is the case, please see https://www.drupal.org/project/convert_bundles/issues/3214960 because I think it may be related and Ive noticed some inconsistent behavior to the userInput variable based on cache settings and that commit may be causing more issues than its solving.
As far as documenting what "Create field values for new fields in target content type" does, it designed to allow you to add new values that exist on the entity type you are migrating to but are are non existent on the content type you are migrating from when converting bundles on large numbers of entities.
So for example you migrate 100 entities of type bird to an entity type animal, and you want to tag all those entities with a term bird that doesnt exist on entity type bird during the migration, adding this step is supposed to allow you to do that.
Post back with more information when possible. Thanks!
Comment #3
el1_1el commentedComment #4
efpapado commentedThanks for your reply. I did some more experimenting based on your question, and I now think there are 2 bugs, in both the cases you describe.
My original use case was about a field that exists in both bundles:
- Bundle
dog, and bundlecat, both have afield_color.- The node 123 is
dog, it has 2 revisions, and has values on all revisions offield_color--- This means that the table
node_revision__field_colorhas 2 lines that have entity_id = 123 and bundle = dog- I run the conversion from
dogtocat, and choose to mapfield_color => field_colorDepending on whether I have clicked "Create field values for new fields in target content type" or not, the result in the database is different:
1a. If the checkbox is NOT checked: the table
node_revision__field_colorhas now 3 lines (the 2 old ones, and an extra new) that have entity_id = 123 and bundle = cat1b. If the checkbox IS checked: the table
node_revision__field_colorhas now 3 lines: The 2 old ones that have entity_id = 123 still have bundle = dog, and the new one has bundle = catIMHO, the 1a is correct and expected behavior, the 1b is wrong (but we can discuss it).
I also did an experiment based on your question:
- Bundle
doghas afield_woof_sound, bundlecatdoes not have afield_woof_sound.- The node 123 has 2 revisions, and has values on all revisions of
field_woof_sound--- Thus the table
node_revision__field_woof_soundhas 2 lines that have entity_id = 123 and bundle = dog- I run the conversion from
dogtocat, and choose thefield_woof_soundto be removed.- After the conversion (whether I have checked "create field values...." or not, the table
node_revision__field_colorstill has 2 lines that have entity_id = 123 and bundle = dog.I would expect that these lines had been deleted, since they are not relevant anymore.
I can start working on a patch, but I think that first we should discuss and agree on what the behavior should be.
Comment #5
efpapado commentedI'm uploading a patch that solves part of the problem: If a field is set to "remove", all its data will be deleted from the field and the field_revision tables.
Comment #6
el1_1el commentedsorry. i just cannot reproduce your error of multiple revisions in either case on an older version of mariadb. Could you specify if you are using postgres or what db version you are using? i'll have to set up a docker instance with that info to try and reproduce the issue.
As for the delete revision patch, i personally like that revisions are kept even on though the prior version is a different bundle since it allows you to change back and is less permanent, but would welcome feedback from others on that change. maybe make it an option?
Comment #7
efpapado commentedMariaDB 10.5.8
Comment #8
el1_1el commentedso i just cant reproduce 1b. I set up cat, dog and color as a taxonomy term, a text list and a plain text field and converted back and forth several times and could not reproduce the behavior you found. it always converted bundle to all cat and all dog in node_revision__field_color_list, node_revision__field_color and node_revision__field_color_taxonomy