Inject a serialization format into database key/value storage

Refactors an existing API or subsystem for consistency, performance, modularization, flexibility, third-party integration, etc. May imply an API change. Frequently used during the Code Slush phase of the release cycle.

A key/value store MUST NOT care for the serialization format being used to begin with — its sole responsibility is to store a (string) value and retrieve it. The serialization format only needs to be consistent for each instance of a key/value store.

As a concrete use-case, the (file-based) configuration system currently expects data to be encoded and decoded in YAML.

Proposed solution

Establish Drupal\Component\Serialization as a core component that provides default implementations for serialization formats used in Drupal.

Inject a serialization format into each key/value store instance.

Notes

This issue only adds the PhpSerialize serialization format, which is currently used by key/value store implementations.

One thing which I really try to understand is the following. Why do we define all this methods as static? Can we assume that all typical serialization bits don't really have dependencies?
In additional to that I wonder why it is not possible to reuse the Serializer interface from symfony, just one example:

The underlying technical premise is that these serialization classes are just some utility-alike classes, which should be usable in a standalone fashion by simply calling the encode() and decode() methods. The latest patch for Json clarifies that we're using that class that way throughout core already.

All of the planned serialization classes (Json, PhpSerialize, Yaml, Xml) are just trivial wrappers around either native PHP core functions or utility classes (Yaml). None of them needs additional configuration beyond the Drupal-specific flags that we're hard-coding. As these are all of the dominant serialization formats today, I do not foresee that we'd be adding any further classes than those four.

Symfony's Serialization component is a very complex piece of code, which has a different intention: Instead of simply encoding and decoding data into and from a specific serialization format, it allows serializers to interact with every single element in the process, in order to validate and normalize each value, to resolve references and linked resources, and to allow other code to participate in the process. Such a very controlled and granular serialization is the use-case of the REST module in core, in which the serialized/encoded data is to be treated like untrusted external user input (similar to user input in forms). That's very different to these simple + standardized serialization format classes.

Note that I was able to perform two interesting serialization format switches in the parent issue already: (1) As an experiment only, I switched the State service to store data in Json instead of serialized PHP. (2) The primary objective: I was able to switch the active configuration from Yaml to Json (and even PhpSerialize) — but of course, the latter is only possible with the additional k/v FileStorage implementation of the parent issue.

@catch: Both yes and no... out of the default serializer implementations, all of them do support primitive data types, but only PhpSerialize supports e.g. serialization of class instances/objects. Whether it is legit and makes sense to use a particular serializer depends on the use-case.

@pwolanin: I've been trying to avoid that question, because it's an implementation detail of user-space code. It's a user-space decision what exactly gets stored in a particular key/value service instance. The backends do not care, because it's a hashtable that's compound of strings/bytes only; keys and values.

The question is not what the common denominator of all serializers + backends is — but instead, how many custom, one-off key/value use-cases needlessly have to re-invent the wheel from scratch, because this stuff is hard-coded right now.

The KeyValueStore component is an abstraction that provides access to a concept, offering various implementations. You should be able to leverage the concept; you don't necessarily have to futz with "the" default key_value service.

Forgot one aspect in #29 regarding data types:

Similar to the Memory backend in core, I learned that some alternative backends do not need a serializer, as they're capable of storing native PHP data types via their corresponding PHP extensions. (can't remember which one, but might have been redis)