Please, prepare your MR for a review. Be sure to write a summary and a focus and create gitlab
comments for the reviewer. They should guide the reviewer through the changes, explain your changes
and also point out open questions. For further good practices have a look at our review
guidelines
All automated tests pass
Reference related issues
Up-to-date CHANGELOG.md (or not necessary)
Up-to-date JSON schema (or not necessary)
Appropriate user and developer documentation (or not necessary)
How do I use the software? Assume "stupid" users.
How do I develop or debug the software? Assume novice developers.
Annotations in code (Gitlab comments)
Intent of new code
Problems with old code
Why this implementation?
Check List for the Reviewer
I understand the intent of this MR
All automated tests pass
Up-to-date CHANGELOG.md (or not necessary)
Appropriate user and developer documentation (or not necessary)
The test environment setup works and the intended behavior is reproducible in the test
environment
In-code documentation and comments are up-to-date.
Check: Are there specifications? Are they satisfied?
The problem results from a non-null replacement in a property which should not have a replacement. The non-null replacement is a residual from a previous run of this method's else clause (below) on the property of the parent entity (in the same transaction).
A bit of context: Both the child's and the parent's properties are wrapping the same object under the hood. This wrapping is caused by the inheritance job. However, since the replacement is just a implementation detail and only needed for the correct storage of properties in the backend, we can simple remove it here, because the parent entity has already been written to backend.
For completeness, there is another possibility for a fix: We could, at some earlier point, disentangle the parent's and the child's property by cloning the underlying object. However, this seems to be much more hassle, because the nice thing about them sharing the same property object under the hood is that we don't need to update them both when id's are being resolved, the description, the datatype or other additional information is added (during inserts) and so on... And this convenience was just the reason why they share the same object in the first place.
NOTE: Previously, the bug occurred when this line (i.e. the else clause) is executed on the parent but not on the child, because this line sets a replacement.
The problem results from a non-null replacement in a property which should not have a replacement. The non-null replacement is a residual from a previous run of this method's else clause (below) on the property of the parent entity (in the same transaction).
A bit of context: Both the child's and the parent's properties are wrapping the same object under the hood. This wrapping is caused by the inheritance job. However, since the replacement is just a implementation detail and only needed for the correct storage of properties in the backend, we can simple remove it here, because the parent entity has already been written to backend.
For completeness, there is another possibility for a fix: We could, at some earlier point, disentangle the parent's and the child's property by cloning the underlying object. However, this seems to be much more hassle, because the nice thing about them sharing the same property object under the hood is that we don't need to update them both when id's are being resolved, the description, the datatype or other additional information is added (during inserts) and so on... And this convenience was just the reason why they share the same object in the first place.