Closed (works as designed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
entity system
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
8 Jan 2015 at 08:18 UTC
Updated:
8 Jan 2015 at 19:56 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
larowlanComment #2
dawehnerLooks totally reasonable!
Comment #4
larowlanThis blocks #2403873: FileFormatterBase does not retain unsaved entities (files) which is major (data-loss) so bumping
Comment #5
alexpottCommitted 4243b60 and pushed to 8.0.x. Thanks!
Thanks for adding the beta evaluation.
Comment #7
plachPlease revert this commit: the previous solution was meant exactly to avoid exposing the value outside the class, as it's an implementation detail. We have a proper API to check the value:
EntityReferenceItem::hasNewEntity().I'd use a protected constant if they were available...
Comment #8
larowlanShould we set it to RTBC to get committer eyes?
thanks for explaining - should we add a comment documenting as such to prevent this happening again?
Comment #9
plachGood idea :)
Comment #10
alexpottreverted
Comment #12
plachComment #13
dawehnerSorry, I could have maybe known that from passive listening in ghent.
Comment #14
effulgentsia commentedAdded docs in #2404221: Document that EntityReferenceItem uses a static to protect access to a constant
Comment #15
jibranHere is the doc updated patch. Just for the record I knew this @fago told @plach in IRC why we should make this a static. I thought I could find something in #2232477: Fatal when adding new fields with NOT NULL constraints in a base table that contains existing entities but there is nothing this is the patch where @plach updated it from constant to static #2232477-104: Fatal when adding new fields with NOT NULL constraints in a base table that contains existing entities.
Comment #16
jibranSorry for the cross post I'll post the patch in other issue.