The entity config query is in and the aggregation query system is ready, and it's surprising how little new code was necessary for it -- mostly a little refactor of the existing SQL implementation to make it more reusable and of course a lot of tests -- written with the help of dawehner, thanks! There are a few big issues left: split the entity controller into a CRUD controller and the real controller. Once users become EntityNG, roles need to use the existing entity reference item. Same for taxonomy terms and their hierarchy.

Many issues are progressing/being done: the Field API to CMI conversion is nearing some 600kb. Field and entity types are being converted to the new entity API -- node is making huge progress, and it's definitely the worst. Entity reference made it in. We now have metadata for config inspired by kwalify.

As it is now firm that a MongoDB DBTNG driver will be necessary, I have reopened an old issue and written a small patch to allow database drivers outside of the core directory. This issue met some political resistance (I can't claim I found any technical reasoning in the issue aside from "we cannot do that") so I am not quite sure whether it will make it in -- I have asked Dries to decide on it to cut the chase. As we would need to instruct people to put the DB driver in the right place anyways, at worst the drivers will go besides the core drivers as they did in D7, it's just going to make core upgrades harder. But then again, if you use git, even upgrades won't be harder, so it's truly not a biggie. Just another bitter day in the core queue -- there are a just bit more of them than I'd like in this cycle.

Of course, the big hurdle of making Views default to entity queries is on the horizon as well, and I had some conversation with dawehner already about it. This is a bit hard to put to writing because my thoughts are still forming. So, one important part of Views is the query builder, especially the default SQL one. However, entity query contains another query builder and once the aggregation queries get in, their power will roughly be equal. Of course, not everything is an entity and there will still be outlying cases that the SQL query engine can do but the entity query engine can't. So, we want to show the full gamut of possibilities to the end users in such a crafty way that entity queries are ran when possible and the Views SQL query builder kicks in only when necessary. Of course, if an entity is not in SQL then SQL queries are straight out. Now, Views does not easily yield to all this, some changes to the way data is defined will be necessary. We need to take a good hard look at the way sort/filter/etc handlers are created too so that within the confines of single inheritance we can still reuse them. Thankfully, there's ample time for this past feature freeze -- all the way till API freeze.

Commenting on this Story is closed.