The getEntity Method of \Drupal\entity_reference_revisions\Plugin\migrate\destination\EntityReferenceRevisions calls $this->updateEntity() after creating a new (possibly stub) row. If the row is a stub from the migrate_lookup plugin, then the bundle key is set in the row's emptyDestinationProperties array, and subsequently deleted from the entity, causing an error on save. updateEntity() should only be called on existing entities.
In addition, the method does not allow for creation of new revisions of an existing entity during a migration. It either updates an existing revision or creates a whole new entity.
What Should Happen:
If a reference_id is provided, it should load an update that revision. If it isn't and an id is provided, then it should load that entity, update it, and create a new revision. If neither are provided, it should create a new entity, process a possible stub, and return.
Comments
Comment #2
mikelutzHere is a fix. The current class doesn't appear to have test coverage, and I don't have time to create one from scratch right now, but I will try to do so in the next days.
Comment #3
heddnNeeds work because needs tests.
Comment #4
mikelutzI found the existing test class, and updated the data set to Check for what I would expect the behavior of the getEntity() function should be.
Comment #5
heddnI'd like to see the failures.
Comment #7
mikelutzComment #8
heddnThe default for migrating entities when passing only the entity_id without the revision_id is to update the default record. That's encoded into the most base of Entity destination classes for quite some time. However, I see the need/desire to override this feature. So I've added some tests and provided this as a configurable option. Do you think it will make folks happy to have both methods?
Comment #9
heddnDo we do change records for ERR? Flagging. But I think this is good for final reviews.
Comment #10
mikelutzThis looks good, and will definitely work to solve my problem over in paragraphs, and minimizes the changes to anybody using the code now. One nitty suggestion:
$entity->setNewRevision defaults to false on entity load, so $entity->setNewRevision(FALSE) is unnecessary, but I like it because it makes the code clearer. For consistancy, either explicitly set $entity->setNewRevision(FALSE) if the config isn't triggered, or remove the unneeded one above it.
Otherwise, +1 for RTBC
Comment #11
heddnre #11: I've removed it above. In thinking about it, this is a strait up bug fix. If someone had experienced the problem, they would know about it. So removing the CR tag.
Also bumping to Major, since it blocks stability for field collection and paragraph migration efforts.
Comment #12
quietone commentedI have read the issue and checked that patch with the code inspection of PhpStorm. I'm not very familiar with entity reference revisions nor the use of ConfigurablePluginInterface but it all looks good to me. Thanks for helping me to learn more about those.
I found a few things, mostly to help with readability.
Whoa, data is the plural, datum is the singular. It is the foreach that should change to
foreach ($data as $datum). But I see there are three total instances of 'datas' in this file, so it is the norm here. Because of that no need to fix it in this patch. Maybe a novice followup to fix those?Can we add another set of parenthesis to be extra clear about the order of operations? The similar statement in the elseif following has the extra set and is easier to read.
Can this just be entity_id? It would make the large if block that follows a lot easier to read.
As well as then be in agreement with the comments that refer to $item_id as the entity_id.
Yes, lets unblock the field collection and paragraph migrations!
Comment #13
mikelutzFunny, I thought the same thing about the 'datas' when I saw them, but I was trying to avoid changing things beyond the issue. I didn't actually add them, but there was a codesniffer issue with the line that I went ahead and fixed in the original patch. Anyway, easy enough to change them out right here, along with the other recommendations. As I said before, it always makes me happy when a patch works well enough that we can sit and bikeshed over variable names.
Comment #14
quietone commented@mikelutz, thanks, that is so much easier to read now.
I reckon this is good to go.
Comment #16
miro_dietikerHa, this whole $data / $datum thing made me struggle and i spent a few seconds:
https://www.theguardian.com/news/datablog/2010/jul/16/data-plural-singular
It makes me feel like we're coding in latin now?
Never seen this term used this way in english...
Still committed as-is, looked great otherwise.
Comment #17
mikelutzHa! I won't post an opinion on data are vs data is, but unless you are referring to more that one of the Star Trek : The Next Generation character, datas is definitely wrong, lol.