Inject a serialization format into database key/value storage

+  public function __construct($collection, SerializationInterface $format, Connection $connection, $table = 'key_value') {
↑
+  function __construct(Connection $connection, SerializationInterface $format) {

Hm. This difference in argument order is unfortunate and bad DX. The format should always come first (or after $collection).

Let's make that consistent.

Make MemoryStorage override StorageBase constructor instead of using a confusing $format default of NULL.

I think this is ready to fly.

Feedback, anyone? :-)

3: kv.format.3.patch queued for re-testing.

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.

Merged 8.x.

1. Renamed $format variable to $serializer.
2. Adjusted phpDoc accordingly: s/serialization format/serialization class/g.
3. Removed serialization class injection from StorageBase on @msonnabaum's request.

Inject serializer into DatabaseStorageExpirable.

Sorry, last patch was bogus. (Only interdiff was correct.)

Inject serializer into user TempStoreFactory, too.

1. Fixed GarbageCollectionTest unit test.
2. Fixed TempStoreDatabaseTest unit test.

I hope it is OK if I move this back to RTBC — the adjustment to also inject a serializer into KeyValueExpirable instead of hard-coding PhpSerialize is really minor and was the only remark in #14.

I actually copied the code from the non-expirable implementation (and only forgot to update tests accordingly, hence the hiccups ;-)).

After further discussion on #2208609: Move Json utility class into Drupal\Component\Serialization + #2208633: Add a Yaml class to Drupal\Component\Serialization + IRC...:

Moved Drupal\Core\Serialization into Drupal\Component\Serialization.

Updated issue summary accordingly.

Can we move forward here?

@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)

Merged 8.x + Adjusted for committed sister issues.