This document discusses the history and evolution of using MongoDB as a database backend for Drupal. It describes how early versions of Drupal had some support for MongoDB through field storage and entity storage drivers. However, full MongoDB support was not possible due to limitations in how Drupal handled things like modules, date formats, text formats, and business logic. Drupal 8 addressed these issues through its new configuration management system and dependency injection container, paving the way for better MongoDB integration through drivers for storage, routing, caching, and more. The document advocates for MongoDB distribution and granular storage controllers to fully realize MongoDB support in Drupal 8.

1. Drupal and MongoDB
or the road to APIs

2. Contrary to popular belief...

3. We had APIs for a long time.

4. We actually designed them.

5. Antwerp, 2005

6. 2007: Drupal 5
• Pluggable sessions
• Pluggable cache
• Only six cache_get calls in core

7. Drupal 7

8. 2008: Field API
• First "real" API
• Data model
• Separation of concerns
• Remote and non-join databases
considered: pluggable storage

9. 2009: When the world
changed
• February 3: Drupal Field API
committed
• February 11: first public MongoDB
release
• June 11: NOSQL event. 100 slots.
Gone in hours.
• NowPublic SCAN uses MongoDB.

10. Drupal MongoDB is born
• November 28: first Drupal-MongoDB
talk
• November 29: Damien Tournoud
commits the field storage driver.
• This was possible.

11. 2010: we go live
• EntityFieldQuery is written
• August: Examiner.com goes live

12. MongoDB worked
(to some extent)

13. What went well?
1. Entity-field storage: node, comment,
user...
2. Session (frequent writes)
3. Watchdog (capped collection)
4. Cache

14. What worked out so-so?
• Blocks. Unmaintainable solution.
• DBTNG. Noooooo!

15. But it didn't really work...

16. Where were things stored?
1. List of modules: system table
2. Date formats:
• date_format_type
• date_formats
• date_format_locale tables
3. Text formats:
• filter
• filter_format tables
4. Arbitrary contrib
• arbitrary table

17. Business logic / settings
1. Field widgets, formatters:
a. Some info hook
b. settings stored in an arbitrary table
c. handled by arbitrary callbacks
2. Cache, query:
a. variable_get defines include file (whole
file!)
b. variable_get defines settings

18. Consequences
1. Even with a SQL abstraction driver,
full MongoDB is practically
impossible.
2. Pluggability is totally arbitrary

20. Drupal 8
One way to rule them all

21. Where are things stored?
1. List of modules: CMI
2. Date formats: CMI
3. Text formats: CMI
4. Arbitrary contrib: CMI or bust

22. 1. Defined in a dependency injection container:
easy and uniform to change
2. Annotated classes: every kind of plugin has
the same metadata definition
3. Again, all settings in CMI
How are things handled?

24. So how will MongoDB fit?
1. Inject via the DIC
2. Sweep up the remaining little via a DB
driver, but this is limited.

25. MongoDB distribution
1. Necessary to be able to install without
MySQL
2. Ability to change things early and keep them
changed

26. • Very granular controllers
• Separate storage controller
• Very little code necessary per entity
type
• Easy to support contrib
New Entity System

27. New drivers
1. File usage
2. Flood
3. Routing
4. Node access (huge potential in
stored arrays)

28. Routing
• Drupal 7: replace the 3883 LoC
menu.inc
• Drupal 8:
o MatcherDumper is 147 LoC
o RouteProvider is 265

29. CMI "driver"
1. CMI canonical is YAML file
2. Plus caching
3. We have a cache driver
4. For speed on queries, do not
serialize on cache_config (other bins
might have objects/arrays so
serialize needed)
5. Bonus: pluggable import.