Change Details

Currently, RevisionStore directly uses a BlobStore to store slot content, calling Content::serialize() to turn a Content object into a blob. There is no reason to hard code this, however. Some kinds of Content may better be stored in a different way, e.g. using a dedicated SQL schema, or in a column store. To allow this, RevisionStore should not use a BlobStore directly, but rather use a ContentStore, which may or may not be implemented based on a BlobStore. The ContentStore interface would be very similar to the BlobStore interface, but would take Content objects instead of raw data blobs: public function getContent( $contentAddress, $queryFlags = 0 ): Content; public function storeContent( Content $content, $hints = [] ): string; The default implementation would be based on BlobStore, Content::serialize, and ContentHandler::unserializeContent. To allow other storage mechanisms to be applied, a wrapper could be used that delegates to the correct ContentStore based on the content model (when writing) and address prefix (when reading).

Currently, RevisionStore directly uses a BlobStore to store slot content, calling Content::serialize() to turn a Content object into a blob. There is no reason to hard code this, however. Some kinds of Content may better be stored in a different way, e.g. using a dedicated SQL schema, or in a column store. To allow this, RevisionStore should not use a BlobStore directly, but rather use a ContentStore, which may or may not be implemented based on a BlobStore. The ContentStore interface would be very similar to the BlobStore interface, but would take Content objects instead of raw data blobs: ```lang=php public function getContent( $contentAddress, $queryFlags = 0 ): Content; public function storeContent( Content $content, $hints = [] ): string; ``` The default implementation would be based on BlobStore, Content::serialize, and ContentHandler::unserializeContent. To allow other storage mechanisms to be applied, a wrapper could be used that delegates to the correct ContentStore based on the content model (when writing) and address prefix (when reading).

Currently, RevisionStore directly uses a BlobStore to store slot content, calling Content::serialize() to turn a Content object into a blob. There is no reason to hard code this, however. Some kinds of Content may better be stored in a different way, e.g. using a dedicated SQL schema, or in a column store. To allow this, RevisionStore should not use a BlobStore directly, but rather use a ContentStore, which may or may not be implemented based on a BlobStore. The ContentStore interface would be very similar to the BlobStore interface, but would take Content objects instead of raw data blobs: ```lang=php public function getContent( $contentAddress, $queryFlags = 0 ): Content; public function storeContent( Content $content, $hints = [] ): string; ``` The default implementation would be based on BlobStore, Content::serialize, and ContentHandler::unserializeContent. To allow other storage mechanisms to be applied, a wrapper could be used that delegates to the correct ContentStore based on the content model (when writing) and address prefix (when reading).