Drupal and MongoDB
or the road to APIs
Contrary to popular belief...
We had APIs for a long time.
We actually designed them.
Antwerp, 2005
2007: Drupal 5
• Pluggable sessions
• Pluggable cache
•  Only six cache_get calls in core
Drupal 7
2008: Field API
• First "real" API
• Data model
• Separation of concerns
• Remote and non-join databases
considered: plugg...
2009: When the world
changed
• February 3: Drupal Field API
committed
• February 11: first public MongoDB
release
• June 1...
Drupal MongoDB is born
•  November 28: first Drupal-MongoDB
talk
•  November 29: Damien Tournoud
commits the field storage...
2010: we go live
• EntityFieldQuery is written
• August: Examiner.com goes live
MongoDB worked
(to some extent)
What went well?
1. Entity-field storage: node, comment,
user...
2. Session (frequent writes)
3. Watchdog (capped collectio...
What worked out so-so?
•  Blocks. Unmaintainable solution.
•  DBTNG. Noooooo!
But it didn't really work...
Where were things stored?
1. List of modules: system table
2. Date formats:
•  date_format_type
•  date_formats
•  date_fo...
Business logic / settings
1. Field widgets, formatters:
a.  Some info hook
b.  settings stored in an arbitrary table
c.  h...
Consequences
1. Even with a SQL abstraction driver,
full MongoDB is practically
impossible.
2. Pluggability is totally arb...
Drupal 8
One way to rule them all
Where are things stored?
1. List of modules: CMI
2. Date formats: CMI
3. Text formats: CMI
4. Arbitrary contrib: CMI or bu...
1. Defined in a dependency injection container:
easy and uniform to change
2. Annotated classes: every kind of plugin has
...
So how will MongoDB fit?
1. Inject via the DIC
2. Sweep up the remaining little via a DB
driver, but this is limited.
MongoDB distribution
1. Necessary to be able to install without
MySQL
2. Ability to change things early and keep them
chan...
• Very granular controllers
• Separate storage controller
• Very little code necessary per entity
type
• Easy to support c...
New drivers
1. File usage
2. Flood
3. Routing
4. Node access (huge potential in
stored arrays)
Routing
• Drupal 7: replace the 3883 LoC
menu.inc
• Drupal 8:
o  MatcherDumper is 147 LoC
o  RouteProvider is 265
CMI "driver"
1. CMI canonical is YAML file
2. Plus caching
3. We have a cache driver
4. For speed on queries, do not
seria...
Webinar: MongoDB and Drupal 8 - Life without SQL
Webinar: MongoDB and Drupal 8 - Life without SQL
Upcoming SlideShare
Loading in …5
×

Webinar: MongoDB and Drupal 8 - Life without SQL

5,832 views

Published on

Drupal, the popular PHP content management system, has undergone vast changes since its last stable release more than two years ago. While Drupal 7 already allowed for some integration with MongoDB, you will be able to run Drupal without any SQL in Drupal 8. Learn how a few seemingly unrelated initiatives played perfectly into this and how you can use Drupal with MongoDB.

Published in: Technology

Webinar: MongoDB and Drupal 8 - Life without SQL

  1. 1. Drupal and MongoDB or the road to APIs
  2. 2. Contrary to popular belief...
  3. 3. We had APIs for a long time.
  4. 4. We actually designed them.
  5. 5. Antwerp, 2005
  6. 6. 2007: Drupal 5 • Pluggable sessions • Pluggable cache •  Only six cache_get calls in core
  7. 7. Drupal 7
  8. 8. 2008: Field API • First "real" API • Data model • Separation of concerns • Remote and non-join databases considered: pluggable storage
  9. 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. 10. Drupal MongoDB is born •  November 28: first Drupal-MongoDB talk •  November 29: Damien Tournoud commits the field storage driver. •  This was possible.
  11. 11. 2010: we go live • EntityFieldQuery is written • August: Examiner.com goes live
  12. 12. MongoDB worked (to some extent)
  13. 13. What went well? 1. Entity-field storage: node, comment, user... 2. Session (frequent writes) 3. Watchdog (capped collection) 4. Cache
  14. 14. What worked out so-so? •  Blocks. Unmaintainable solution. •  DBTNG. Noooooo!
  15. 15. But it didn't really work...
  16. 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. 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. 18. Consequences 1. Even with a SQL abstraction driver, full MongoDB is practically impossible. 2. Pluggability is totally arbitrary
  19. 19. Drupal 8 One way to rule them all
  20. 20. Where are things stored? 1. List of modules: CMI 2. Date formats: CMI 3. Text formats: CMI 4. Arbitrary contrib: CMI or bust
  21. 21. 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?
  22. 22. So how will MongoDB fit? 1. Inject via the DIC 2. Sweep up the remaining little via a DB driver, but this is limited.
  23. 23. MongoDB distribution 1. Necessary to be able to install without MySQL 2. Ability to change things early and keep them changed
  24. 24. • Very granular controllers • Separate storage controller • Very little code necessary per entity type • Easy to support contrib New Entity System
  25. 25. New drivers 1. File usage 2. Flood 3. Routing 4. Node access (huge potential in stored arrays)
  26. 26. Routing • Drupal 7: replace the 3883 LoC menu.inc • Drupal 8: o  MatcherDumper is 147 LoC o  RouteProvider is 265
  27. 27. 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.

×