Use entity_load for fieldapi field handlers

Quoting myself from the prequel issue (#936196: Don't use entity_load to display fields):

The current patch includes both code paths (entity_load, and assembling the entity ourselves), configurable by setting "add fields to query" in the views field definition, but if entity_load proves to be not that big of a slowdown, then we can just remove the current "simulating" code, since the contrib modules really need the data in the query, and not the fake entities we are constructing for ourselves.

So, we now need benchmarks! Any volunteers? Would allow dereine & me to focus on some more coding...

Any particular method for benchmarks you would suggest? Are render times from the Dev module good enough?

subbin'

sub

Subscribing.

I'm not sure you'll see a lot with devel timings (although memory usage would be useful), worth posting though.

The ideal thing here would be to set up a view, then profile using xhprof with and without the entity load setting (do this a couple of times each side to rule out other caching). You can then see the overall change in time/cpu/memory and how much in absolute time/percentage entity_load() takes (since that ought to be the only variable between the two requests).

Would also make sense to profile with a view that specifically includes and renders the node body as a field, since that should show the difference with and without the check_markup() caching discussed in other issue.

Subscribing.

Looked into the patch, since I try to handle this issue #1006176: Add support for field based translation.
Current patch seems not to solve the issue since we still have JOINS to the field tables.
As far as I understand the JOIN is used to determine the entity_type of the field - couldn't this also be done by checking the base_table of the view or the relation that's used for the field?

Okay, so we agreed that we need entity_load() and we need it quickly, regardless of benchmarks. It has no sane alternative.
We also agreed that contrib modules like sphinx don't need our pre_render() frankenstein, just the fields in the query itself. This makes the patch smaller & easier to understand.
However, grouping support landed, so we need to make sure that one still works as it should.

Here's an in progress patch. It actually doesn't work for some reason (entity_id for one field is NULL, breaking everything...), but I'm too tired to debug it further.

Also not sure if the entity_type hack (calculate it ourselves and add it to the query instead of adding the column itself) is sane, or if it even helps grouping.

And if we could get the entity_id without joining on the field table, that would eliminate the whole join... However, it's not as easy as fetching the base id, since the field could be under a relationship...

sub

It's not working because

+        $objects = entity_load($entity_type, $oids);

Needs to be:

+        $objects = entity_load($entity_type, $object_ids);

That's why I shouldn't post patches that late.

Let's try this one.

The last patch contained a few hunks too many.
dereine has confirmed on IRC that the code is working.

I'm working on eliminating the join completely by default, but I guess the current patch can be committed if it becomes urgent...

Okay, so the join is added only if "add field to query" is TRUE, or we are using grouping, or there's a filter / sort.

Smells like final version.

Now with 100% less prefixes.

Let's just tweak it a bit :)

Even better. Replacing old "object" terminology which is older than the term "entity".

Not seeing where the "Add Fields to Query" option is...

I see, that makes sense thanks. I would rather do it in code anyway.