ContentEntityBase get and __get() works differently

As a variant I've added check if <?php $field->isEmpty(); ?> and run <?php $field->applyDefaultValue(); ?>, it resolve a problem with default field value on views and on node page.

For the testbot

IMO this is major WTF.

Didn't look closely yet, but applying the default value for empty fields is *wrong*, we can not do that.

Having a non-required field with a default value and then not actually saving a value is a perfectly valid thing to do. get() and __get() cannot be different in regards to that?

applying the default value for empty fields is *wrong*

I agree with that, but maybe we need way to get default value for field if it empty.

I've found this when tried to resolve this issue https://www.drupal.org/node/2348729, one of test failed, because views do not display default field value.

To reproduce this try to add node and after that add new field of type boolean to node content type, and show this field in views. Views must display default field value, but it doesn't.

Still a problem.

I suspect this actually belongs in the entity system component?

I think what @Wim refers to as DrupalWTF is adding a new field with a default value and then existing entities do not have it. Yeah, that is weird, but this is the wrong way to fix it. As I said above, this patch is wrong and has nothing to do with the issue title or summary.

Just because there is a default value doesn't mean that a user can not explicitly remove that and save it as empty. That is 100% valid and we must not break that.

The only case in which we could consider it is for required fields.

Also keep in mind that if we would do this, this would only fix it for entities when loading them. It does nothing to fix it in the database, so this might in fact be more confusing than the current behavior. If you'd load/edit/view your entity then the correct value would be there, but when you try to do an entity query against it for example it would not work.

Downgrading and set to normal until something can prove to me why this is a bug and can come up with code that does not break valid use cases. The only thing I can I think of right now is provide a UI to re-save all entities in a batch and set an explicit default value there.

This feels like a duplicate of the #2346019: Handle initial values when creating a new field storage definition after looking at the comments but IS is describing a different problem. We need an IS update.

Discussed with @andypost in IRC.

I was able to clarify the misunderstanding that get() and __get() behave differently in regards to fields and default values. They do not. The fallback logic in __get() that initializes things to NULL is *only* about non-fields and is part of the BC layer that we can not remove until 9.x and I think we have issues for that.

Closing.

We still have issues like #1919834: Field instance got no default value when created in field UI about the specific problem of new fields not having a default value on existing entities.