The drop is always movingYou know that saying about standing on the shoulders of giants? Drupal is standing on a huge pile of midgetsAll content management systems suck, Drupal just happens to suck less.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.]Drupal makes sandwiches happen.There is a module for that

Drupal 8 progress from my / MongoDB perspective: update #8

Submitted by nk on Wed, 2012-11-21 06:16

Another week, another kernel patch. This one moves the kernel initialization to very, very early in the bootstrap process, just after settings.php is read. So, the MongoBundle can override everything easily. Great! There's a patch in the queue which I will turn my attention to once this is in which puts the database service in the kernel. More on this a little later.

I dabbled a bit in multilingual CMI again, this time worked on metadata a little. While surely MongoDB+Drupal doesn't need multilingual CMI, we need everyone in the community to be happy with CMI and not code around it because their use case is not supported.

A lot of patches are ready: date formats, flood storage, email and taxonomy reference fields for the new entity API. Once the taxonomy reference patch is in, I can promptly add a test based on it to the entity query relationships patch and that's ready -- unlike last week when it was in a rough but working shape now it's really nice and ready just it has no configurable field test and without that it really can't go in. And, there are no field types to test with as yet, that's why I wrote the taxonomy reference field item patch.

Next up, well, it's November 20 and the feature freeze is on December 1, what's Plan B? What happens if the new batch API is not finished or not accepted because it's late? Perhaps not even a patch to make batch API storage pluggable? What's with authmap? In general, there will remain some SQL queries, no matter what, in some darker corners, some lesser loved core modules / functionality, and of course some contrib. For this, the battle plan is to use a database driver and make a gigantic switch on every known SQL string which will then execute a mongodb helper function for each. This was written for D7 as a proof of concept and it's doable just there were way too many SQL queries running all the time to make this a really viable plan. CMI is the initiative that fixed this mess, we love CMI for removing all sorts of crappy tables from the critical path. Also, shipping and installing a database driver was very inconvenient. Well, once the early kernel patch and the database-as-service patch is done, any module (in fact the early kernel patch allows even for non-module bundles but that's just icing on the cake) can deliver a database driver. So that's where we will fall back to and so the next week will be the database-in-the DIC patch, finishing entity query relationships and the new batch API. Perhaps I can take a stab at removing and making OpenID just use a text field instead (or perhaps we need an authmap field type, no UI, attachable only to users). We will see how much I can accomplish in the short time left.

Past feature freeze, the big, big, big issue is making Views use entity queries in all cases if it can.

Commenting on this Story is closed.

Submitted by Anonymous on Wed, 2012-11-21 07:40.

Many of the "convert X to an injected object and put it in the DIC" issues can still happen post-1 December. Not all, but many. Every one we manage to do will help with Mongo compatibility, because it means we can easily swap it out if needs be.

So the story doesn't end on 1 December. The focus just narrows a bit. ;-)