11:15 - 11:45 Document-Oriented Storage
Drupal 6 was strongly tied to MySQL and its table format. Drupal 7 introduced the concept of Entities and Fields. Now comes Drupal 8, and it needs a new Copernican Revolution: switching to storing and managing generic semi-structured "documents".
We need to review the state of the art in this domain and discuss implementation options. The objective is to solve some of our current pain points:
- A single API can store both content and configuration (because they are the same)
- The API can have built-in synchronization options to easily push both content and configuration between environments
- The API can improve our scalability by materializing some of our queries (... and removing the need for the two manual denormalizations we have in Drupal 7 core: tracker and taxonomy)
We will discuss the idea of implementing a Document-oriented API in Drupal 8. The potential features of the API could be:
- Stores document as-is, without transformation
- Can perform queries deep inside the documents (à la MongoDB), including across relationships; and can also materialize them (ie. save the result set and maintain it across time)
- Revisions everything and addresses content by their revision IDs (à la Git)
- Supports mixed storage, allowing querying across several storages (including local filesystem storage, database storage, remote storage, etc.)
- Can leverage both standard SQL (via DBTNG) and proper document-oriented database engines (MongoDB, CouchDB, ...)