Installing / importing new configuration no longer writes directly the config storage but uses the full Config object which fires events on write/delete. This allowed me to start on writing a config entity query class which subscribed these events and denormalized data suitable for queries. catch then voted this one down, saying it's premature optimization. So a simpler implementation has been submitted which loads all configuration entities of a certain kind (like all Views) and then filters/sorts/etc. It's not yet commited (not even RTBC) but then again, I expect it'll be in soon because the code was deemed straightforward by the reviewers so far and it's extremely well tested. If necessary, the optimization code is still in the patch/in a git sandbox. The work that went into the denormalized version was not wasted because that code went into the entity module and this change have revealed a nice number of critical upgrade issues. Also the tests were totally salvageable -- in fact, the current implementation could be called test driven development.

The modules subystem have received a beautiful cleanup by moving the module code into a pluggable class. Although we do not plan to plug this one, the generic cleanup already done and made possible is in general a very good thing. Right now, the whole module-theme system works almost by accident only. There is a really ugly ball of circular dependencies as system_rebuild_{module,theme}_data fires hooks. If you are interested in untangling this mess, I have a whole list of issues filed already, please contact me.

Roles became configuration. 11 tables remain unpluggable from the minimal profile. In less great news, while marcingy have rolled a nice, pluggable openid storage patch, the chances of it getting in is slim. And I am afraid I must agree with this reasoning: "OpenID is just a feature module, it's not a deep underlying subsystem... how far we really want to take this pluggable storage because the resulting code is *way* harder to understand, and if D8 becomes "you can never ever write a query directly without a layer of abstraction" that's not going to be remotely friendly to developers". So, OpenID and other feature modules likely will keep their queries and we will support those. This is fine, this is Plan B as outlined months ago: we will use a MongoDB DBTNG driver, with a fixed list of SELECT queries supported. As long as that list is fixed, this works. And that's what didn't work in Drupal 7. While it is quite unlikely that a contrib module will decide to work with, say, the OpenID tables directly, in Drupal 7 there were so many fundamental tables, so many reasons to use them directly -- and now most tables are just gone or have nice enough APIs that people will choose to use those instead of direct queries. So, if contrib does not go 'bare metal' (much) then Plan B is entirely viable. This also means that education on the new APIs will be extremely important for us, to tell the developers how nice the new APIs are so they keep away from SQL.

I have a very hard time proceeding with the new Batch API. It sure would be a win for developers and users both but it's quite some work, with converting all the batches in core (including install and update, just the thought makes me shudder) and for us, the win is very very small, we are talking of four queries altogether. However, if I find the time I would still be glad if it'd be done -- anyone interested in helping? This is not the kind of work where deep Drupal 8 knowledge is needed, anyone with a good grasp on how to code Drupal can chime in -- and hone their Drupal 8 skills en route.

To the list of sprints (Portland, Dublin, Midwest, Prague) we can now add LinuxFest Northwest April 27-28th, a month before Portland: a Drupal sprint is being planned!

Commenting on this Story is closed.