We have a Field CRUD API task: "CRUD: API to load single field for single entity: Should take field, entity, and entity_id as arguments. Needed for Materialized Views."
I started to write this function, thinking it would be easy (ha). I decided to make it exactly like field_attach_load() except for a single object and with another argument for the single field to load, like this:
<?php
field_attach_load_single($obj_type, $object, $field = NULL, $age = FIELD_LOAD_CURRENT);
?>My thought was that if you do not specify $field, you get all the fields for $object, otherwise you get just that one field.
Sadly, I bumped into a problem. If I am loading only a single field for an object, do I invoke hook_field_attach_load() like I would if I were loading the full object? It seems like that might confuse some hook_field_attach_load() implementation that expects all the fields for an object to be present. However, if I do not invoke hook_field_attach_load(), then whoever uses this API function will not see the results of whatever contrib modules are installed that modify the results of loaded fields.
We could declare a hook_field_attach_load_single() to handle this conflict.
However, I realized while implementing the function that it should? needs to? check the field data cache for the object, in which case it always has all the fields for the object available anyway.
So I am thinking we just do not need field_attach_load_single at all. If MV needs a single field, it can just load the full object. If the fields aren't cached yet, they will be after the first call, so if MV needs to load multiple fields for the same object, all but the first call will be a cache hit.
Comments? David?
Comments
As a counter-argument, I
As a counter-argument, I just noticed this in node_fieldable_info():
<?php// Node.module handles its own caching.
// 'cacheable' => FALSE,
?>
No Field Attach API uses the 'cacheable' indicator yet (that's another task I am about to implement), but when it does, it invalidates my argument about not needing field_attach_load_single.
So, what do we do about hook_field_attach_load when loading individual fields? I'll ponder.
We currently have that on
We currently have that on the 'view' side : field_view_field() is a one-field equivalent for field_attach_view(), that returns the fully themed and access-checked output of a single field. It's used in D6 Panels integration (my original plan was to use it for Views too, but views have specific display options that do not fit well - whatever).
And, unsurprisingly, it currently forgets to care about hook_field_attach_view()...
We also have uses for a one-field form element. CCK UI uses that for the 'default value' widget, athough it's not abstracted out to an official API function (CCK calls field_field_form() directly). Could also be used for Panels (panelize your node form) and Views (Views Bulk Operations)
Makes me wonder if we need to generalize a mechanism for one-field variants for all our attach ops. Would cascade down to one-field variants for field_invoke() / field_invoke_default() (our iterators), and hook_field_attach*().
I'm not sure of how convoluted this would make the task of writng a hook_field_attach_*() implementation. Aside from fieldgroup.module, I still have no clear use cases in mind.
Actually, should we bother
Actually, should we bother with hook_field_attach_load for the specific "API function to load single field for single entity" ?
IIRC, this is primarily targeted for MV, right ? Should the MV-generated tables mirror the original content of the relevant field_data_* tables (in which case we shouldn't call any additional hook), or include 3rd party after-load changes ?
Again, I miss actual uses cases for hook_field_attach_load() to better understand how we should treat this.
I'm back from vacation now.
I'm back from vacation now. I think it's reasonable for MV to load all fields and just only use what it really needs out of it. It's not the fastest option, but it should be pretty reasonable.