Hi,
I have a simple compound-field with, for the sake of brevity, let's say two, fields: tid
& amount
. Tid is a term-ref, and amount is a integer. I then have a field which is a multi-valued field.
If you var_dump the relevant output from entity_get_property_info it's set as:
field_NN = array(
label => 'NN',
type => 'list<NN>',
getter callback => 'entity_metadata_field_verbatim_get',
field => TRUE,
property info => array(
amount => array(
type => 'integer',
label => 'Amount',
getter callback => 'NN_entity_metadata_field_property_get'
)
tid => array(
type => 'taxonomy_term'
bundle => 'a_vocabulary',
label => 'Term',
getter callback => 'NN_entity_metadata_field_property_get',
options list => 'entity_metadata_field_options_list'
)
)
)
If you then add the related entity 'NN' you get the field 'NN » Amount' added to your list of fields. And you can then choose to add 'NN » Term' as a related entity which will give you the term fields, amongst which is 'NN » Term » Name'.
After both 'NN » Amount' and 'NN » Term » Name' is added to the list of fields, I can var_dump the options['fields']
from the Index entity, and I get the following:
array(
field_NN:amount = array(
name => 'NN » Amount',
type => 'list<integer>',
boost => 1.0,
indexed => 0,
),
field_NN:tid:name = array(
name => 'NN » Term » Name',
type => 'string',
boost => 1.0,
indexed => 1,
)
)
The fault here is that field_NN:tid:name
has its type set to 'string', not 'list'. This is turn causes Search API Solr to choose the field-name ss_field_nn:tid:name
. Then when indexing, this causes an indexing error!
So what I'm saying is: If you have a single-value related entity to a multi-valued related entity, it should be indexed as being multi-valued instead of single-valued as it currently is.
I haven't had time to figure out where the fault is - but I'll probably look into it next week if you want a patch.
Regards
-Morten
Comment | File | Size | Author |
---|---|---|---|
#2 | search_api.nested_list_entities.patch | 973 bytes | drunken monkey |
Comments
Comment #1
fangel CreditAttribution: fangel commentedOkay, so the reason for this is that the $type_prefix/suffix generation in
search_api_admin_index_fields_submit
isn't additive.It only uses the nesting-level from the upper-most wrapper. So in my case in the loop through wrappers will first find the EntityListWrapper, with type
list<NN>
, and then the EntityDrupalWrapper with typetaxonomy_term
.After the EntityListWrapper, the $type_prefix/suffix is correctly set at type< / >, but then it processes the EntityDrupalWrapper which overrides them to blank values.
It's my opinion that the generation should be additive, so that EntityDrupalWrapper adds nothing, instead of overrides with nothing. I don't know if it's intentional that it's not additive, so don't know if this breaks something existing!
I can whip up a patch of how I changed it to be additive, if anyones interested in one (basically initialize $type_prefix/suffix the same place as $name_prefix, and change the =-assignment to .=-assignments).
I can probably also create a way simpler example of this bug - possibly using standard drupal features and not a custom field (I believe a multi-valued taxonomy-ref with a single-value taxonomy-ref as a field should do the trick)
-M
Comment #2
drunken monkeyOh, you're right, that really shouldn't be the case. I thought I had this covered, but seemingly forgot something.
I began to look at this and wondered a bit, as the code in
_search_api_admin_get_fields()
seems correct, but then luckily you already spotted the bug. Yes, it seems the code there is wrong and your approach should fix it. I already tried it out in the attached patch, please see if it fixes your problem.(I just don't really see why the type there doesn't get overwritten in
_search_api_admin_get_fields()
, but as long as the bug is fixed, I'll just assume everything is correct again. ;))Comment #3
drunken monkeyComment #4
fangel CreditAttribution: fangel commentedHi,
The attached patch applies cleanly, and fixes the issue. I can now facet on
f_sm_field_nn:tid:name
. Yay!I can't had a chance to look if this could be corrected in
_search_api_admin_get_fields()
, however seeing as the prefix-building is done by looking at the EntityWrapper info, which I assumes is straight from EntityAPI, the type of ´tid´ will always, and correctly, be set as `taxonomy_term` seeing as there is only a single of them.. (Unless I misunderstood something. I have only been looking at the code for SearchAPI/EntityAPI for 1.5 days, so that's likely)PS, looking forward to hopefully working with you in the future :)
-Morten, version2.dk
Comment #5
drunken monkeyOK, great! Just committed this, thanks for the help!
Comment #6
drunken monkeyAnd once again forgot to change the status …
Comment #7
fangel CreditAttribution: fangel commentedWicked. Thanks. If only other issue queues would move as fast as this one :)