Attached patch adds the $entity_type parameter to field indexing callbacks.

The use case is for fields added to entities other than node which are being indexed. Specifically, we are indexing Field Collections via http://drupal.org/project/apachesolr_field_collection, and some of the fields in the field collections have indexing callbacks that assume they are on nodes (and no way to tell otherwise from $entity).

Comments

brianV’s picture

Just adding that #1838850: Solr indexing callback assumes field is added to a node is dependent on this patch.

nick_vh’s picture

This does not default back to node right? I'm a little concerned if we have handled all indexing callbacks with this? Is this fully backwards compatible with previous API?

brianV’s picture

Nick:

I'm not sure I understand your questions, but I'll attempt to answer them anyways.

Apachesolr itself is completely generic in terms of the entities that it handles, at least insofar as these functions are concerned. If you check the patch, you will see that the extra parameter isn't even used by any of the field indexing callbacks that apachesolr includes.

The problem is when you deal with field like Geofield which need to fetch 'more' info for indexing purposes, and they use functions like field_info_instance() which require an entity type and bundle passed as arguments. In Geofield's case, they used 'node' as the entity type and looked for $node->type as the bundle.

Once they are able to get the entity type, then between the entity type, entity id, the bundle can be fetched with entity_extract_ids.

nick_vh’s picture

Status: Needs review » Reviewed & tested by the community

I'll commit this asap, looks like there is no impact for correct usage of the API

nick_vh’s picture

StatusFileSize
new5.17 KB

I'm still concerned what happens if this

$fields = $function($entity, $field_name, $index_key, $field_info, $entity_type)

Calls a function that is custom and does not support the entity_type argument. Should we find out how many argument a function can take to allow for maximum compatibility throughout the stable version of this module?

nick_vh’s picture

Status: Reviewed & tested by the community » Needs review
pwolanin’s picture

@Nick_vh - not sure about your question. A user-space function will ignore extra params passed to it. Is that your concern?

brianV’s picture

I believe this is the exact conversation we had on IRC prior to you posting #4.

A quick test, if you would like to confim, is to just toss this into a PHP file and execute:


$test1 = 'Hello';
$test2 = 'World';

print test_function($test1, $test2);

function test_function($test1) {
  print $test1;
}

This will just print 'Hello', and won't throw any warnings, notices etc.

Also, this is why PHP provides functions like http://php.net/manual/en/function.func-get-args.php, as we may not always know what arguments are being passed to a function. If you search the drupal codebase for function_get_args(), you will see that there are actually a bunch of use cases where a function is called with arguments passed, despite none being defined in the function signature, and func_get_args() is used to fetch them.

jlk4p’s picture

I have a question. Is this patch part of the 7.x-1.2 version? I tried adding it and it did not work. So I thought it was in that version. But when I attempt to write a callback function for a custom field and pass it the 5 parameters noted above which includes $entity_type, I get an error that argument 5 is missing.

pwolanin’s picture

Status: Needs review » Needs work

patch doesn't apply to 7.x-1.x now

amontero’s picture

Issue summary: View changes
Issue tags: +Needs reroll