Encode/decode data via PHP serialize()/unserialize() for DatabaseStorage (storage controller specific data formats)

Clarifying title. FYI I think this is a good idea. It will be quicker and we will be less reliant on our serializiation/deserialization code from a performance perspective.

Yes I only let the original patch go in because I assumed we'd switch over to this :)

Each database driver needs to be able to define their own method of handling configuration storage. For an RDBMS storing a serialized array makes sense, but for a key-value store storing a serialized array would be nonsense.

Well, no matter what storage, its going to be a serialized array. It may be PHP or XML or JSON or whatever, but one way or another you're serializing an array down to a specific format. That's not going to change at this point.

The issue summary says "serialised php array" so I'm just pointing out that serializing the data into a string doesn't make sense for every storage system.

This issue is about the default database storage driver only, should be zero effect on other drivers either way.

A possible solution for this exists over in #1470824: XML encoder can only handle a small subset of PHP arrays, so switch to YAML and it also might be able to allow for different storage options based on database type through using dependency injection to replace the DrupalVerifiedStorageSQL class.

First effort at moving config encode / decode out of the config interface layer which will allow the DatabaseStorage class to use php serialize. The attached patch takes the following approach:

• FileStorage and DatabaseStorage are implementations of StorageInterface
• StorageInterface defines encode and decode methods:
  • For DatabaseStorage these use serialize / unserialize
  • For FileStorage these use the original config_encode / config_decode functions to work with xml
• Creates a new ConfigStoreInterface to replace StorageBase - this interface has FileStorage and DatabaseStorage objects and manages saving and retrieving config from them

Fixed copying config to database and files directory on module enable.

Improved documentation of the config classes and interfaces

Hm. Yes, we need to untangle the synchronization interface methods from storage controllers. But it might be a good idea to do that only after #1447686: Allow importing and synchronizing configuration when files are updated. That patch stumbled over the StorageInterface methods already and additionally introduces a second notion of how FileStorage and DatabaseStorage controllers may be used. The StorageInterface changes should most probably also be discussed in #1560060: [meta] Configuration system roadmap and architecture clean-up first.

That said, I'm not sure why these changes are necessary for this issue/patch in the first place? We should be able to move the encoding/decoding operations into the storage controllers without the other architectural changes.

Unless I'm terribly mistaken, this should do it.

Code lives in the cmi/config-format-1500238-sun branch (based on config-format-base).

#14: config.format.14.patch queued for re-testing.

Fixed the import of module default configuration.

Fixed ConfigFileSecurityTestCase.

New patch improves some comments and a couple of code tidy ups.

Patch re-rolled after comments from sun on irc: "revert the additional phpDoc fixes" - "because those custom methods will go away entirely, and only the StorageInterface will remain"

Interdiff is for patch in #20

Nice, very nice. The API is so much better! + $data = $this->encode($data); instead of config_encode that's how the world should be, truly.

This seems to cause an infinite loop in the tests. I interrupted the test.

Status: Running tests, 495,389 assertion(s).

Yes, probably was #22 (http://qa.drupal.org/pifr/test/269358) that caused the infinite loop. Setting back.

#25: config.format.23.patch queued for re-testing.

This looks great. Committed/pushed to 8.x.