Follow up for #1869250-37: Various EntityNG and TypedData API improvements
Problem/Motivation
getOriginalEntity() slightly clashes with our current notion of $entity->original during saving/updating
Proposed resolution
Develop a "Plan B" in case we do not manage to kill the BC layer.
Remaining tasks
- brainstorm a plan b.
User interface changes
None.
API changes
To be determined.
Original report by @sun
From: #1869250-37: Various EntityNG and TypedData API improvements
+++ b/core/lib/Drupal/Core/Entity/EntityInterface.php @@ -190,4 +191,23 @@ public function isDefaultRevision($new_value = NULL); + public function getOriginalEntity();This slightly clashes with our current notion of $entity->original during saving/updating, no?
However, if I get this right, then this BC layer is supposed to be removed anyway before release, so I guess the name clash doesn't matter for now.
That said, do we have a "Plan B" in case we do not manage to kill the BC layer before release? Should we perhaps create an issue for such a plan B, tagged with "revisit before release"?
Comments
Comment #1
fagoQuoting myself from http://drupal.org/node/1869250#comment-6893050:
Comment #2
sunOK, in that case, I think we can won't fix this issue, and we'll have to re-evaluate anyway nearby code freeze.
Comment #3
eclipsegc commentedI'm following this now just in case it gets reopened, PLEASE, no plan B. We have got to get everything converted properly and I would 100% advocate holding up release until we do have it all converted.
Comment #4
ianthomas_ukThis function was renamed in #1877638: Rename getOriginalEntity() and remove duplicated functions from ConfigEntityBase then the BC layer was killed in #1983554: Remove BC-mode from EntityNG , no plan B needed so removing revisit tag.