Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Just like entity field in ER
$properties['field_collection_item'] = DataReferenceDefinition::create('entity')
->setLabel(t('Field collection item'))
->setDescription(t('The field collection item'))
// The field collection object is computed out of the value.
->setComputed(TRUE)
->setReadOnly(FALSE)
->setTargetDefinition(EntityDataDefinition::create('field_collection_item'))
->addConstraint('EntityType', 'field_collection');
After that we can remove the methods like getFieldCollectionItem
and calculate the value in setValue ofr getValue methods.
In D7 it make sense not to make a ER field but in D8 ER is in core so I think we can leverage that.
Comment | File | Size | Author |
---|---|---|---|
#43 | field_collection-extend_entity_reference-2509254-43.patch | 215.74 KB | jmuzz |
|
Comments
Comment #1
jibranI think we should keep the original property as it is and add a new computed field.
Comment #2
jmuzz CreditAttribution: jmuzz commentedSo instead of getFieldCollectionItem() we'd get an entity reference and then use getValue() on that. I'm not sure I see the advantage of that. Field collection items are connected to their host via a reference to their ID, but that seems like an implementation detail to me since field collection items behave like data in their host instead of an independent entity being referenced.
Could you explain a bit more about what entity reference provides that field collection would benefit from?
Comment #3
jibranMoving project.
Comment #4
jmuzz CreditAttribution: jmuzz commentedComment #5
jmuzz CreditAttribution: jmuzz commentedThis is the approach that the people involved in 8.x-2.x are attempting to implement.
Comment #6
jmuzz CreditAttribution: jmuzz commentedIt might be worth doing to gain access to the entity reference formatters. That would solve #2761505: Allow to choose a display mode in the "fc items" formatter settings
Comment #7
jmuzz CreditAttribution: jmuzz commentedWe'd be able to make use of entity reference REST functionality too. #2614292: Add normalizers for Field Collection Items (to enable REST/JSON API support)
Comment #8
jmuzz CreditAttribution: jmuzz commentedAnother feature of entity reference that would benefit people using field collection: #1131872-15: Fieldcollection items that have a taxonomy field assigned and a term given are not shown on the corresponding taxonomy page
Comment #9
jmuzz CreditAttribution: jmuzz commentedI think it would be worth doing sooner rather than later if possible.
Making field collection items an extension of entity references makes more sense to me than having field collection items hold an entity reference.
Comment #10
jmuzz CreditAttribution: jmuzz commentedComment #11
jmuzz CreditAttribution: jmuzz commentedI've gotten a start on this. I've done some minimal manual testing and it seems the basic features are working. It doesn't currently enjoy any of the theoretical benefits of using this approach. The tests are dying and I'm running into some difficulties getting information from simpletest. I'm going to make another issue for that.
Comment #12
jmuzz CreditAttribution: jmuzz commentedCreated an issue about difficulties getting a meaningful error message: https://www.drupal.org/node/2764783
Comment #13
jmuzz CreditAttribution: jmuzz commentedTests are passing now. I don't want to commit it until it is making use of at least one of the benefits of this change.
Comment #14
jmuzz CreditAttribution: jmuzz commentedThere are some unnecessary options on the field settings form from entity_reference that will need to be removed or hidden.
Comment #15
jmuzz CreditAttribution: jmuzz commentedIt's repeating an entity reference behaviour where it adds different options for entity types to reference to the field creation form, so for example "Taxonomy term" can be selected under "General" field types and it will be created as a field collection field that references taxonomy terms instead of field collection items.
Comment #16
jmuzz CreditAttribution: jmuzz commentedThe field collection items formatter now extends the one from entity reference. It allows the user to choose a display mode for the field collection items, which is one thing field collection 8.x-1.x couldn't do before.
This patch should include an update since the name of one of the field properties has changed from 'value' to 'target_id'.
Comment #17
jmuzz CreditAttribution: jmuzz commentedComment #18
jibranPatch looks grreat. This is a big change and will break existing sites.
debug code?
Comment #20
jmuzz CreditAttribution: jmuzz commentedYes it was.
I fixed the interface problems I mentioned.
The update still needs to be written.
Comment #22
jmuzz CreditAttribution: jmuzz commentedForgot a file.
Comment #23
jmuzz CreditAttribution: jmuzz commentedI thought such an update would only have to change some column names or something but it turns out to be a huge can of worms. There is a longstanding issue about supporting such changes: https://www.drupal.org/node/937442
There is some field settings that could be updated, and berdir has linked from here to a solution which involves manually updating field schema. https://www.drupal.org/node/2554097
I'm thinking it won't be necessary to write an update for this because it is just an alpha version still and tedbow has said that there aren't many installs of it yet. https://www.drupal.org/node/2628388#comment-11204273
Comment #24
jibranTell me about it. In #2555027: Support non-numeric entity ID's the only change was
and have look at
dynamic_entity_reference_update_8001
how massive it is.Comment #25
jmuzz CreditAttribution: jmuzz commentedI did have a look at it and it's a good example. With this and the one @berdir posted I was able to put together an update. I've only tested it with one fairly simple dataset.
Comment #26
jibranUpdate function looks good. I'll request chx to have a quick look at it.
Comment #27
jibranHere are some review points:
Can we please use short array syntax in this patch? Also the indentation is wrong.
This is wrong you are not changing any config instead of this you should use
$entity_field_manager->getFieldMapByFieldType()
see #2555027: Support non-numeric entity ID's for reference.Use the table mapping to get the table name and column name please have a look at #2555027: Support non-numeric entity ID's for reference.
Use a local variable ;-)
The getter calls can be avoided by using field mapping.
short array syntax please.
Can we please change it to
$bundle = $this->bundle(); $entity->$bundle->appendItem(['entity' => $this]);
?Short syntax please. :-)
Comment #28
jmuzz CreditAttribution: jmuzz commentedThanks for the feedback.
It lead to me taking a look at the policy discussion about array syntax and creating #2769205: Switch to short array syntax.
Comment #29
jmuzz CreditAttribution: jmuzz commentedThis addresses 1 to 8.
I'm leaving it needs work because there is no upgrade path test yet.
Comment #30
jibranInterdiff looks great. NR for test bot.
You can't make sure the name of the table or column like this. We do shorten these strings if these are bigger then the the allowed limit. Unfortunately, we have to use the api here.
Comment #32
jmuzz CreditAttribution: jmuzz commentedMinor reroll.
Comment #33
jmuzz CreditAttribution: jmuzz commentedI addressed the review points and added a test with some additions to get it passing.
I still want to add some asserts to the test.
Comment #35
jmuzz CreditAttribution: jmuzz commentedComment #37
jmuzz CreditAttribution: jmuzz commentedThe update test class verifies all the schema changes so I guess there isn't much left to test for. I added some checks for the field values.
Comment #38
jibranGreat to see the green patch with update test. Very nice work @jmuzz.
I think this one update hook is doing way too much work. We should split it into 3 update hooks.
Comment #39
jmuzz CreditAttribution: jmuzz commentedIt is a large update, but it all has to be done for it to reach the next working state. I don't think I can support or make tests for if only part of it is done.
When the API supports changes like this properly then updates like this won't need to do so much work.
Comment #40
jmuzz CreditAttribution: jmuzz commentedReroll for short array syntax.
Comment #41
jmuzz CreditAttribution: jmuzz commentedReroll that preserves the support for displaying subfields in twig from #2628648: Allow access to subfields from twig.
Comment #42
jibranThank you I do understand your point but all I'm saying that we should move this change to follow up and add another update hook for this.
This is an isolated change from target_id.
Comment #43
jmuzz CreditAttribution: jmuzz commentedI suppose that is an unrelated change.
I removed that and the new description for revision_id in the schema so the revision related columns won't need to be updated.
Comment #44
jmuzz CreditAttribution: jmuzz commentedI created #2772379: Revision ID should be unsigned and have a description for the change to revision IDs.
Comment #45
jibranPerfect! Thank you for moving it to new issue. We have update path we have update path tests so this is ready. We could test it on other databases drivers but I don't think that should block this issue.
Comment #46
fagoI agree the change makes sense - not only does it give more compatibility with things like widgets or formatters, it also improves DX as the field collection field does not use special column names any more.
For widget/formatter compatibility it's a bit sad, that core's compatibility handling does not cover extended plugins, but we could easily solve that with some drupal_alter() in a follow-up.
Code looks pretty a decent and even has upgrade path test coverage! Awesome!
Comment #48
jmuzz CreditAttribution: jmuzz commentedThanks again for all the valuable feedback!