I have a node reference field that allows multiple values, but when I tried to index it, single index is created, which causes errors in solr:

org.apache.solr.common.SolrException: ERROR: [doc=ohhv8s/node/8872] multiple values encountered for non multiValued field is_field_category: [8161, 1]

Files: 
CommentFileSizeAuthor
#23 1900036-node-reference-63.patch1.11 KBwonder95
PASSED: [[SimpleTest]]: [MySQL] 520 pass(es). View
#21 apachesolr-cardinalityfix-1900036-node_reference_with_multiple_values-21.patch1.31 KBswentel
PASSED: [[SimpleTest]]: [MySQL] 513 pass(es). View
#20 apachesolr-cardinalityfix-1900036-node_reference_with_multiple_values-20.patch1.31 KBswentel
PASSED: [[SimpleTest]]: [MySQL] 513 pass(es). View
#15 apachesolr-cardinalityfix-1900036-node_reference_with_multiple_values_v3.patch1.15 KBremimikalsen
PASSED: [[SimpleTest]]: [MySQL] 513 pass(es). View
#11 apachesolr-cardinalityfix-1900036-node_reference_with_multiple_values_v2.patch1.15 KBremimikalsen
PASSED: [[SimpleTest]]: [MySQL] 513 pass(es). View
#9 apachesolr-cardinalityfix-1900036-node_reference_with_multiple_values.patch1.11 KBremimikalsen
PASSED: [[SimpleTest]]: [MySQL] 513 pass(es). View

Comments

Nick_vh’s picture

What version of Solr are you using? I've encountered this with Solr 4. I've seen this happening with hierarchic taxonomy fields. Can you try latest dev version and see if it is resolved? (patched something about this problem last weekend)

Nick_vh’s picture

apachesolr_nodereference_indexing_callback should probably check if the field is single valued and only allow 1 value if that is the case.

Could one of you tell me what is in the $field_info for your specific case?

function apachesolr_nodereference_indexing_callback($entity, $field_name, $index_key, array $field_info) {
 dsm($field_info);
  ....

remimikalsen’s picture

I'm using 7.x-1.1 regularly and it seems 7.x-1.x-dev (downloaded today) introduces a bug on entity-reference to taxonomy terms. I have a field that is an entity-reference to an unlimited number of taxonomy terms of a particular vocabulary. The apachesolr status page for facets identifies the field as an ss_ field, but it's attemted indexed as an sm_ field (which of course fails terribly on the solr-side). Solr 3.6 here, but it's really not a Solr problem.

I'll try to be more explicit on the nature of this bug when I have some time on my hands. For now I'll just have to "put it out there".

R

Nick_vh’s picture

No time is no excuse, really. Just put a debug statement there and paste it here. :)

remimikalsen’s picture

* apachesolr_entityreference_indexing_callback
* dd($field_info);

Gives:

(Note the multiple field; here it holds nothing. The stable version holds "1")

Array
(
    [indexing_callback] => apachesolr_entityreference_indexing_callback
    [map callback] => apachesolr_entityreference_facet_map_callback
    [index_type] => string
    [facets] => 1
    [query types] => Array
        (
            [0] => term
        )

    [facet missing allowed] => 1
    [dependency plugins] => Array
        (
            [0] => bundle
            [1] => role
        )

    [name callback] => 
    [hierarchy callback] => 
    [facet mincount allowed] => 
    [multiple] => 
    [field] => Array
        (
            [entity_types] => Array
                (
                )

            [foreign keys] => Array
                (
                    [node] => Array
                        (
                            [columns] => Array
                                (
                                    [target_id] => nid
                                )

                            [table] => node
                        )

                )

            [indexes] => Array
                (
                    [target_id] => Array
                        (
                            [0] => target_id
                        )

                )

            [settings] => Array
                (
                    [handler] => base
                    [handler_settings] => Array
                        (
                            [behaviors] => Array
                                (
                                    [views-select-list] => Array
                                        (
                                            [status] => 0
                                        )

                                )

                            [sort] => Array
                                (
                                    [type] => none
                                )

                            [target_bundles] => Array
                                (
                                    [nav_styrk] => nav_styrk
                                )

                        )

                    [target_type] => taxonomy_term
                )

            [translatable] => 0
            [storage] => Array
                (
                    [type] => field_sql_storage
                    [settings] => Array
                        (
                        )

                    [module] => field_sql_storage
                    [active] => 1
                    [details] => Array
                        (
                            [sql] => Array
                                (
                                    [FIELD_LOAD_CURRENT] => Array
                                        (
                                            [field_data_field_nav_styrk] => Array
                                                (
                                                    [target_id] => field_nav_styrk_target_id
                                                )

                                        )

                                    [FIELD_LOAD_REVISION] => Array
                                        (
                                            [field_revision_field_nav_styrk] => Array
                                                (
                                                    [target_id] => field_nav_styrk_target_id
                                                )

                                        )

                                )

                        )

                )

            [id] => 115
            [field_name] => field_nav_styrk
            [type] => entityreference
            [module] => entityreference
            [active] => 1
            [locked] => 0
            [cardinality] => -1
            [deleted] => 0
            [columns] => Array
                (
                    [target_id] => Array
                        (
                            [description] => The id of the target entity.
                            [type] => int
                            [unsigned] => 1
                            [not null] => 1
                        )

                )

            [bundles] => Array
                (
                    [node] => Array
                        (
                            [0] => utdanningsbeskrivelse
                            [1] => yrke
                        )

                )

        )

    [name] => field_nav_styrk
    [module_name] => Entity Reference
    [display_name] => Nav kategori
    [bundles] => Array
        (
            [0] => utdanningsbeskrivelse
            [1] => yrke
        )

)
Nick_vh’s picture

So 'multiple' seems to be false, apachesolr correctly gives it a singular field. I assume that the assignment of entityreference keys is done incorrectly somehow.

Could you also do a debug of the apachesolr_entity_fields();function? Perhaps we have to force all reference fields to be multiple in any case?

remimikalsen’s picture

In apachesolr_entity_fields() there is:

 $row['field'] = $field;

Append immediately after:

if ($row['field']['cardinality'] !== 0 && $row['field']['cardinality'] !== 1) {
  $row['multiple'] = TRUE;
}

Solves it for me. Maybe the !==0 is redundant. In any case, cardinality -1 or >1 are the multiples.

Nick_vh’s picture

Interesting, could you make a patch? And add some documentation about the cardinality field.

eg.: cardinality (integer): The number of values the field can hold. Legal values are any positive integer or FIELD_CARDINALITY_UNLIMITED.
http://api.drupal.org/api/drupal/modules%21field%21field.module/group/fi...

So it's only when the value == 1, we should set a field to single. -1 is unlimited and anything else means multiple. I'm not sure what 0 does. Also, we might want to rename multiple throughout the codebase to cardinality to sync more with D7?

remimikalsen’s picture

FileSize
1.11 KB
PASSED: [[SimpleTest]]: [MySQL] 513 pass(es). View

See attached patch.

Nick_vh’s picture

Status: Active » Needs work
+++ b/apachesolr.moduleundefined
@@ -2017,6 +2017,11 @@ function apachesolr_entity_fields($entity_type = 'node') {
+        if ($row['field']['cardinality'] !== 1) {

We also want to check if the field is set, so you can do an isset($field['cardinality]) && $field['cardinality'] !== 1

remimikalsen’s picture

Status: Needs work » Active
FileSize
1.15 KB
PASSED: [[SimpleTest]]: [MySQL] 513 pass(es). View

Attached patch v2.

I assumed it must hold positive integer or FIELD_CARDINALITY_UNLIMITED, but better safe than sorry; guess an isset doesn't "cost" all that much.

ianthomas_uk’s picture

Status: Active » Needs review

Is there a reason to use !== instead of just !=? Are we sure it will never be '1'?

Setting to needs review to get picked up by automated tests.

remimikalsen’s picture

I'm not sure of that, But if a '1' is found, maybe it should be fixed by the code that violates the documented behaviour?

R

Nick_vh’s picture

Status: Needs review » Needs work

You can just use !=, makes it less strict, but more certain that even custom code will be picked up.

remimikalsen’s picture

FileSize
1.15 KB
PASSED: [[SimpleTest]]: [MySQL] 513 pass(es). View
Nick_vh’s picture

Status: Needs work » Needs review
mkalkbrenner’s picture

Status: Needs review » Reviewed & tested by the community

Something similar here:

ERROR: [66e11o/node/3] multiple values encountered for non multiValued field
ss_field_testimonial

In our case, field_testimonial is a multi value entity reference on a node.

#15 solved the issue.

albert78’s picture

Patch from #15 solved my issue as well.

steven.wichers’s picture

Also confirming #15 seems to have fixed the issue for us.

swentel’s picture

FileSize
1.31 KB
PASSED: [[SimpleTest]]: [MySQL] 513 pass(es). View

Been bitten by this as well. Rerolled for 80 chars limit and removed the isset(). @nick, field api adds defaults, also for cardinality (defaults to 1), so the property is always set. Still RTBC.

swentel’s picture

FileSize
1.31 KB
PASSED: [[SimpleTest]]: [MySQL] 513 pass(es). View

BAH

Nick_vh’s picture

Version: 7.x-1.x-dev » 6.x-3.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Not sure if it needs backport, but marking as such until someone confirms. Committed to 7.x-1.x

wonder95’s picture

FileSize
1.11 KB
PASSED: [[SimpleTest]]: [MySQL] 520 pass(es). View

Attached is a patch for a backport to 6.x-3.x.

wonder95’s picture

Status: Patch (to be ported) » Needs review
Nick_vh’s picture

Status: Needs review » Closed (works as designed)

Drupal 6 does not have the cardinality config, only multiple. So due to that it is not applicable and I am going to close this issue.