![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
In the name of full disclosure, as I have mentioned in a previous post, I am paid by 10gen to make Drupal more MongoDB friendly. This does not just mean the contrib modules (mongodb and efq_views) but core work as well. Our goal is to make Drupal 8 work with just MongoDB, without any SQL. It just so happens that the cornerstones for this are things the community wants anyways: the configuration management initative happens to remove a lot of reliance during the boot process -- no system table, no date_format* tables, no variable table. We care a lot about the plugin system because well, we need to change a lot of default, SQL-bound implementations. While converting more and more of our code base to use the dependency injection pattern allows for unit testing and cleaner code it also allows for unprecedented pluggability as well. Views in core interests me because it will make it possible for people to start using the better-for-MongoDB-users Drupal version sooner.
There's no need to worry that things are becoming evil and convoluted just to satisfy some crazy NoSQL agenda: I work within the same framework as everyone else and I do not have a red phone to the core committers. I try to stay away from architectural decisions as well and just work on what's agreed on. So far I feel it's been working out well.
Commenting on this Story is closed.
I just started looking at MongoDB for a non-Drupal, non-web project. I was immediately struck by the natural fit of the MongoDB model to the needs of Drupal node storage and the potential for greater efficiency. I look forward to the fruition of this work.
I think its great that our paths cross so much! Keep up the great work! (Gábor Hojtsy)
We had an access control BoF today and the subject of NoSQL came up. Any ideas how we can build a NoSQL-friendly replacement for {node_access}, or so we need database-specific storage methods?
There's no such thing as "NoSQL-friendly". If you are asking for a MongoDB-driven solution then I would say, in general, that you'd store, into your entity, an array of, I dunno what to call it, "specifiers". I am thinking of user groups... taxonomy terms... whatever you can deduce from the current request context. So all the access system would be: deduce specifiers from context (user id from cookie, taxonomy term from URL etc etc), add the list of current specifiers into the query and that's it. Heck, most of the time you can do just user ids: BSON documentation limit is 16MB, you can comfortably throw in a couple million 32 bit integers and get away with it.
Edit: I doubt you can make this into a speedy SQL solution -- this depends on MongoDB having array indexes.