SqlContentEntityStorage does not unserialize base field data

I think this is a duplicate of #2232427: Allow field types to control how properties are mapped to and from storage,

This is really critical. I think whatever #2232427 might come up with in the long run, this should be addressed now.

See also Core/FieldType/LinkItem:

// Unserialize the values.
    // @todo The storage controller should take care of this, see
    //   SqlContentEntityStorage::loadFieldItems, see
    //   https://www.drupal.org/node/2414835
    if (is_string($values['options'])) {
      $values['options'] = unserialize($values['options']);
    }

Well, somebody smarter then me decide this. It does come down to this:

I just used the gelocation module (see referenced by issue) and I could neither use views, nor store data because of this issue. However, a pretty simple setValue function in the fieldType definition of the geolocation field fixes this.

So: you kinda run unto unexpected fails. But: you have to use a contrib module, which is not aware of this issue. Core itself does take care of this on each occasion I found.

So my conclusion: reduce to major or even normal and move to 8.1, as changing this now would break the API.

Maybe update the docs somewhere to point to the issue, that serializing is handled automatically, but unserializing is not, for schema fields set to serialize.

Yes I think this is an API annoyance for contrib modules, not a critical bug or contrib project blocker, so downgrading. Tagging for rc target triage since I'm not sure we can fix this in a minor release - would mean we have to avoid double-unserialize resulting from the change.

This is completely untested, so more something to get the ball rolling that something RTBC-able. (Needs tests in any case.)

Also not sure what to do regarding BC here. Would be really sad to have to punt this to D9, but not really sure how we can do this without breaking stuff.

So the problem is that there might be other field types like LinkItem that currently unserialize manually (because they have to). If we then fix this behavior, they might try to unserialize the already unserialized data.

Although, thinking about this, I guess they should always be wrapping the unserialize() in a is_string, just like LinkItem, so ... ?

We could always introduce a new marker interface for that but that would also make it harder to implement new field types in 8.1+.

(Just removing the inaccurate (and now irrelevant) beta eval.)

I still think this is a duplicate of #2232427: Allow field types to control how properties are mapped to and from storage, also it's not at all clear which contrib modules it's an issue for at this point. Marking duplicate again.