This is a follow-up to [#update_7008], for an issue reported by a few individuals in the comments after that ticket was closed.
Reported as follows:
When updating FC from 1.0-beta 5 to the June-23-16 dev version.
Running PHP Update:
Pending update:
field_collection module
7008 - Update fields in field collections already set to use Entity Translation.The error reads:
Update #7008
Failed: Exception: Unable to save a field collection item without a valid reference to a host entity. in FieldCollectionItemEntity->save() (line 442 of .....\field_collection\field_collection.entity.inc).
Gnucifer has said:
It can be solved by writing a clean-up script, for example: drush php-script delete-orphaned-field-collections.php. Basically write an entityFieldQuery loading all field collections, check if ->hostEntity() returns false, and delete those field collection items. You might want to check the data first so you are not deleting critical data, and salvage it in some manner.
Either update 7008 should just skip over orphaned field collections to avoid failing, or it should actually delete orphaned entities. It sounds as though it ought to be fine to delete them, but in the interests of avoiding potential data loss, I suggest they should just be skipped over. Whilst orphaned entities are not really supported by this project, there's no need to let them trip the update up when they could just be easily skipped over. I don't think we can really expect users to sort out corrupted data themselves, or get them to run a separate script.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | field_collection-orphans-2759157-6.patch | 1012 bytes | wranvaud |
| #5 | field_collection-orphans_in_update-2759157-5.patch | 969 bytes | nadavoid |
| #3 | field_collection-orphans_in_update-2759157-3.patch | 965 bytes | james.williams |
Comments
Comment #2
mastoll commentedThanks @james.williams for moving this to a new issue - and so gracefully.
I know orphaned field collections aren't among the objectives of this project, but I would run a separate script for it, if i didn't have to write it.
I can't work on this for the next week, but I'm not giving up!
Comment #3
james.williamsHere's a quick attempt at fixing the update to delete orphaned field collections instead of attempting to deal with their translations. PLEASE NOTE this is entirely untested work!
Comment #4
mastoll commentedI applied this patch and deleted 6 orphaned field collection items! And the latest version of FC (with the patch) installed and updated fine.
I have a custom module that does not work with any version of FC that is newer than beta5. I had hoped that this orphaned field collections issue was the reason behind that problem - sadly it isn't.
At least I have this out of the way. Thank you for your interest in this issue and effective patch.
Comment #5
nadavoid commentedAdding
TRUEto the$item->save();to speed up processing by skipping host save.Comment #6
wranvaud commentedAs suggested in the issue description this patch does not delete the orphaned field_collections but will show the orphaned identifiers and display a message to delete them.
Comment #7
james.williamsI don't think we can really expect users to sort out the corrupted data themselves, so printing out the IDs isn't going to be of much benefit in general (although I can understand that being ideal for certain developer/user relationships!). On larger sites, the list of orphaned field collections could be very long too.
For me, the patch from comment 5 seems ideal, but it depends where the project maintainers want to take this really. They may be comfortable with shifting the action on to the end-users.
Comment #8
liberatrUsed the patch in #6 successfully to unblock a stuck upgrade.
Comment #10
jmuzz commentedI think it should be safe to remove them. Thanks for the patch.
Comment #12
jaykandari+1 for #6. this fixes 7008 update hook, if we have orphaned field_collection items.
Comment #13
nikm commentedmay be it's my setup, but #6 deletes all my 'en' entities along with 'und' which makes my site empty for 'EN'/default language.
Comment #14
james.williamsOh gosh, @nikm is onto something... field collections on non-default revisions will get wiped out. I've opened #2942188: Field collections on old revisions get deleted.
Comment #15
m.stentaI am dealing with orphan field_collection data as well. I originally found this currently open issue: #2763395: Field collection doesn't delete children data
It seems that issue is trying to fix the root cause of the orphaned data.
The commit that was made for this issue (if I understand it correctly) attempts to clean up orphans, but ONLY on translatable fields (leaving the orphaned data for non-translatable fields), AND it does not address the root cause, which means more orphans will happen later.
Given that it also causes the issue described in #2942188: Field collections on old revisions get deleted, I suggest reverting this commit. A more complete solution is needed.
Comment #16
m.stentaUpdate: #2763395: Field collection doesn't delete children data is not actually the cause of my orphaned data. Still trying to figure out what the actual cause is. I think the rest of my comment is still relevant.