Progress on what? Glad you asked... let's first go through a few important concepts:

Entity

An object of a certain entity type defined in hook_entity_info. This hook describes the really rudimentary metadata like labels and things like "id key" -- the name of the object property containing the primary identifier. It also defines which class handles loading of the entity. Note that there is not a word here mentioning a database! We have an object, the object has properties, end of story. Some of the data might happen to sit in a database, some other might be dreamed up by magic pixies, who knows. Core only handles loading and some rudimentary searching of entities and it only fires hooks around saving and viewing them. But there is no unified API to actually view or save one. The search class is called EntityFieldQuery (in short: EFQ). We will get back to it.

Entity API

A contrib project which adds the missing pieces to the core entity API: metadata about those object properties, saving and viewing entities. Also provides Views integration.

Views

Ah, we all know this one. This is a query builder module where the result of the query can be displayed in a number of ways. This multitool is nothing compared to the versatility of this module. One of the ways it can display is called fields which approximately maps to displaying database columns one by one (and not as a more complex whole like an entity). This naming will lead to big confusion soon... Now, the aforementioned Entity API Views integration allows for properties to be added as a views field and some properties are such that you can sorting and filter on them. Those that allow sorting and filtering tend to be stored in a database. For example, the URL of the entity is not stored (it's generated by the Entity API module) and so it can't be filtered on.

Field API

A field is a piece of data which can be attached to an entity. Although it has its limitations, this one is an actually architected API and it makes some sense. There is a field storage layer, there are widgets to enter data and formatters to display them. These pieces are not tightly coupled -- the storage layer can handle any sort of field, the same widget might be used on different entity types etc. Views contains field API integration on its own. Which means you can add a field API field as a views field. Some of them allows to be sorted or filtered on.

So what I am working right now is a module called efq_views which allows the core EntityFieldQuery class to be used as a query backend for Views. Most importantly this allows the MongoDB field storage engine to integrate with Views nicely. I have written a mongodb query backend for Views many, many years ago and it was not a hard thing to write, honestly, but the problem was: how to tell Views about the structure of data in MongoDB? Now, Field and Entity APIs come together and solved this problem for us. All is left to get the pieces actually working. The efq_views module was written by bojanz and dawehner a year ago but abandoned since. To make sure it works and allow some necessary refactoring, I have written some tests already, most importantly about displaying entity properties and field API fields as views fields and once the tests were up, refactored the old code to use the Entity API provided entity property views field handlers (phew! long class names too) instead. There are tests for both database stored and derived properties. The tests run on mongodb if the module is present.

A lot more tests are needed for filter and sort functionality -- for each type of data (integer, string, the like) we have a number of operators to test (about a dozen). Once all tests are done, I will do a release.

Then we can start working on impossible things like querying across entites. For example, I would like to see blog posts written by people joined in the last 24 hours. The 'type" property are on the node entity type, the "created" date property is on the user entity type and EFQ has absolutely no notions to do this sort of query. As a first step, I plan to add views field support across such relationships and then we can look at the denormalization necessary for sorts and filters. Adding such field support requires a Views patch which will also be rolled soon, I have talked to the Views maintainers and they are OK with adding a simple drupal_alter where we need it.

Commenting on this Story is closed.