The EntityFieldQuery rewrite is progressing well, finally had a good review from fago. The following patch had a 36KB interdiff on a 120KB patch. Such is life in Drupal core: you try to write something to the best of your abilities, someone smarter comes along, you adjust your code. Now your code and yourself is better if you take the effort to learn from it.

I started working on eliminating the batch table and replace it with queue and replace the batch API screen with a generic queue runner screen. The hardest part for me -- which is done -- was discovering how the JS system actually works, what it does, how can you communicate with it and so on. The exploration module I wrote can be found here. Consider the typical batch API job: some mass operation, say deleting a number of nodes. For this we simply put one job in batch API which then repeats itself until it is done. Every job has its sandbox which, among other things, contains a progress property allowing the system to visualize the progress for the user and terminate the repetition when it gets to 1.0. When a batch contains several non-repeating jobs, we simply show how many of those are done. Now, if we use the queue API and several repeating jobs gets queued then showing a full progress bar will not be possible as the progress of repeating jobs are not visible without dequeuing them. However, we can show the two progress bars that currently exist, namely one with the number of jobs and one with the current job and only show each when it makes sense. Every user will need its own queue. With a proper storage like this we can easily create alternative runners like a block so that the user can continue exploring the site while the batch runs.

Pluggability progresses well: the dependency injection container is now compiled to disk. Next up is the death of the bootstrap container and making the database use the DIC. Everything that encourages the use of the DIC is a net win for us so I am involved in these issues.

Some table efforts are progressing well: marcingy's file usage patch is in, he converted the regional settings so the death of the three date format tables is imminent, his next task is converting the users_roles table to become a field. amateescu did a fantastic job on converting menu links to entities he likely will need help with book module though. swentel is converting field settings to CMI, his patch is almost complete, with only a single test failing.

However, some table efforts are not progressing that well: converting filter settings to CMI has been stalled. Very little progress was ever made on making flood pluggable. There is not even a patch for convert node types into CMI. As far as I understand these can be addressed past feature freeze as these are not major new features -- but also there is a whole month even past BADcamp when these can be safely and swiftly done, the first two are very easy the node type thing might need a little craftiness but at the end of the day, it's not that hard either.

I need to talk to Crell to see how pluggable is the menu_router table with the new router system.

You might notice that I do not mention node_access table. It is simply not going to be supported unless someone writes a pluggable entity access system of which I have doubts at this point. It is accessed in a) a hook_query_alter implementation and that hook we won't fire b) inside node_access but surrounded by module_implements('node_grants') and mongodb module will just hook_system_info_alter any module so it can not be enabled if it implements that. b) will also stop any writes as well.

At BADcamp, I will be sprinting with programmers from examiner.com (marcingy, Zlender and I heard Andy Lasda might join us too) to port MongoDB module to D8 and to actually attempt a boot without SQL. We are fully aware that this will not be possible yet without core hacks as there are still SQL tables around but with a clear vision of where they are headed we will monkey patch the remaining SQL-bound functionality temporarily and see whether the big picture (CMI, K-V store etc) works as intended and use the month after BADcamp to add any major features that turn out to be missing.

Ps. The initial of merge of Views into core is likely happening within 24 hours of this post but almost certainly before the VDC Sprint on the 29th.

Commenting on this Story is closed.