Closed (fixed)
Project:
Drupal core
Version:
8.4.x-dev
Component:
entity system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
23 Mar 2017 at 14:02 UTC
Updated:
27 Jan 2018 at 10:43 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
hchonovComment #3
hchonovAnd the fix for the issue.
Comment #5
tstoecklerAwesome, thank you!
Comment #6
imiksuIs there any way to confirm the problem and fix in UI?
Comment #7
hchonovThe problem could not be reproduced through the default UI, only if you have custom or contrib module which is doing what is being done in the test. As the test is a valid use case I think that it is enough example for what is wrong. This is one issue of series of issues about problems with entity cloning.
For common mistakes regarding this you could take a look at the following issues:
Comment #8
fmrodriguez commentedComment #9
fmrodriguez commentedAssigning by mistake, sorry.
Comment #10
alexpottJust thinking out aloud - but is there anyway we can add a definite test for cloning an entity and ensuring that the clone doesn't have any references back to the original object?
Comment #11
hchonov@alexpott, yes this is possible at least at the moment as we don't have properties which are referencing objects directly - we have only string and array properties currently. If we introduce later a property referencing an object directly we'll have to decide how we'll deal with this case. But this is really out of scope for now and the test is best effort. The good thing about the test is that it will fail each time a new property is defined and we haven't defined its behavior - shared or non shared reference between the translation objects :).
I've discussed this with @tstoeckler as well and here is the patch asserting the properly cloning of entity properties and it tests the use case of entity cloning when initiazing translations and also when simply cloning the entity.
In the test I've defined the properties that are currently not shared between the translation objects, but some of them should be shared in order for consistency or also prevent further problems with entity cloning. Here I only test them accordingly, but in a follow up(s) I am going to make those properties shared across entity translation objects.
Comment #13
alexpottGiven the size of the test changes to #11 I think it is worth getting another community review before committing.
Retrieve the cloned entity's properties.Just a point of style. I wouldn't bother creating the
$properties_filterit doesn't make the code any more readable and is not re-used. Also$properties_clonemake it sound like a clone of the properties which this is not. It's the properties of the $clone entity. So I think$clone_propertiesmakes more sense. I realise that these thought might be a language thing as the implications of different word orders is different in different languages. So it might be simpler just to call it$propertiesThis can be set outside the loop no?
Comment #14
hchonovRe #13:
2.
My bad.. the reflection properties of the entity and its clone are the same and it does not matter if we retrieve them from the entity or from its clone. Renaming to
$properties.3.
Yes,
$translation_unique_propertiescould be defined outside of the loop. I've defined it there so that the code that tests the translation clone is at one place, but I've moved the array definition outside of the loop now.Comment #15
tstoecklerI think the test looks great. Just some minor notes:
So per http://php.net/manual/de/class.reflectionproperty.php#reflectionproperty... this is equivalent to
~\ReflectionProperty::IS_STATIC, no? That would be both shorter and clearer IMO.Can we not instead test for the actual values? I.e.:
etc. We could do an assertion on both the
$entityand the$translationin both cases. What do you think?Comment #16
hchonov@tstoeckler, no, the filter like this will return all the properties without the static ones :). This means private, protected and public properties.
Yes, we could make the test more explicit and test for actual values instead. Will cover that later.
Comment #17
hchonov@tstoeckler, my mistake.. I've overseen that you've meant negation of the static properties. This should work as well.
Comment #18
hchonovRe #15:
1. Done.
2. Now testing at all places explicitly against an expected value - there was one more place - @see interdiff.
I've also noticed that we haven't extended the comment in CEB::__clone, that we break the reference for isDefaultRevision like we mention all the other properties. I've covered this in the new patch as well.
Comment #19
tstoecklerThank you. You know how much I like to nitpick, but as hard as I tried, I couldn't find anything ;-)
Comment #20
alexpottCommitted and pushed ce2aae0 to 8.4.x and a2d2c19 to 8.3.x. Thanks!
Backported to 8.3.x as this change does not have BC implications and is a straight up bug fix.
Comment #24
matsbla commented