Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
If you use an entity reference, a node reference or an user reference as field and set the cardinality to 1, apachesolr detects that correctly and and creates a "ss_field".
But if you use field tarnslation / entity translation to translate these references the callbacks apachesolr_nodereference_indexing_callback(), apachesolr_userreference_indexing_callback() and apachesolr_entityreference_indexing_callback() return all translations as single references.
So the final document that gets sent to solr contains multiple values in a single value field.
The entity / node will never be indexed.
Comments
Comment #1
mkalkbrennerThe solution is that apachesolr must only deal with language neutral references. Everything else must be ignored like everywhere else in apachesolr, which is not aware of node translation or entity translation at all.
I created a patch to solve the issue in that way.
Apache Solr Multilingual will than deal with the multilingual references.
Comment #2
mkalkbrennerAn improved version of the patch that is more efficient.
Comment #3
mkalkbrennerIt's too late in the evening. Now the patch returns the references.
Comment #4
Nick_vhI like this, simplifies the logic a bit
Comment #5
mkalkbrenner... and the current implementation is simply wrong ;-)
In general I think that it's a good approach to only handle the default language and language undefined stuff in apachesolr and leave all multilingual stuff for apachesolr_multilingual.
Comment #6
Nick_vhComment #7
Nick_vhCommitted to 7.x-1.x
Comment #8
pwolanin CreditAttribution: pwolanin commentedI think we should add some code comments there
Comment #9
pwolanin CreditAttribution: pwolanin commentedcommitted
Comment #10
mkalkbrennerI think this issue is not relevant for 6.x-3.x