Add support for field meta conditions in EntityFieldQuery

The following columns are added by field_sql_storage: entity_type, bundle, delete, entity_id, revision_id, language, delta to every field storage table. Out of these, entity_type, bundle, entity_id, revision_id are part of the entity. But delete, language and delta could and should be query-able independently. A new method, quite likely as there is no way to squeeze these into the existing methods. fieldCondition won't work because nothing stops you to add a field column named 'delta' for example ( and it will work as field_sql_storage adds the table name to the field columns while the metadata is named just that).

There is nothing to stop us from adding yet another argument to fieldCondition but oh god please no. it's ugly already. Just have a new method. fieldMetaCondition? Add one for each? fieldDeleteCondition, fieldLanguageCondition, fieldDeltaCondition?

Note that this / these new method(s) likely need delta grouping with field conditions. And maybe language grouping too.

Subscribe

webchick suggest fieldValueCondition -- maybe? I can see the logic but I am wondering whether it will confuse people due to some basic fields like text using a value column.

Having fieldPropertyCondition next to propertyCondition would be awful.
+1 for fieldMetaCondition.

Definitely getting there: comments aplenty and using an anonymous callback to achieve clean code is especially welcome. Of course needs tests. But, the reason I CNW'd it because if you compare fieldCondition and fieldMetaCondition you will be very hard pressed to find any difference but the name of the property we are loading the very same data. Yes to having a separate fieldConditions and fieldMetaConditions array -- but why not have a protected method like protected function foo($property, $field, $column, $value, $operator, $delta_group, $language_group) { copy of fieldCondition just change $this->fieldConditions to $this->property} and then make fieldCondition and fieldMetaCondition call it with the respective $property.

I don't think we should allow querying on 'deleted'. deleted is special, and is handled separately by the EFQ::deleted() method. Allowing it here as well would probably cause some weird clashes.

Other than that, looks good to me - and terrific tests :-)

Yes, I'd say we don't need to add code to explicitly prevent a condition on 'deleted', but we should remove it from the suggestions in the phpdoc, and probably add a note that the delete() should be used for conditions on 'deleted'.

@plach : I don't think I have a strong opinion on this. chx maybe ?

removing deleted is fine

Supported by yched positive review I am confident in marking this terrific patch RTBC (provided the bot comes back green).

I rerolled with even better comments.

Reviewing this, I mainly had concerns around documentation... there was nothing in the docs that explained to me why 'meta' conditions were different from regular conditions, and there was still a reference to + * @see EntityFieldQuery::fieldMetaCondition() which no longer existed.

chx addressed those in #20, and so I committed and pushed that to 8.x and 7.x.

...which I just noticed was the wrong thing to do. :( So chx is going to roll a new interdiff patch. Sorry. :(

Here's a followup -- it's the interdiff between the D7 and the D8 patches.

here it's again hoping the bot picks it up as 7.x

Awesome, thanks. Committed/pushed to 7.x.