Closed barthy-koeln closed 4 years ago
I just realised that the same thing happens if the second field is a single child document and not a collection.
In oder to fix this, one would have to apply the same as above to single nested objects in DocumentFactory::createDocument()
:
[…]
if (is_object($fieldValue) && $field->nestedClass) { // index sinsgle object as nested child-document
$fields = $document->getFields();
$value = $this->objectToDocument($fieldValue);
if (isset($fields['_childDocuments_']) && !is_array($fields['_childDocuments_'])) {
$value = [$value];
}
$document->addField('_childDocuments_', $value, $field->getBoost());
}
[…]
When mapping collection fields of an entity (example below), the
DocumentFactory
might come to a point where the document's_childDocuments_
field already exists, filled with the child documents of one collection. Then, if another collection is added to the_childDocuments_
, this field is already an array, and the array sent toDocument::addField(…)
is inserted into the existing array, which results in nested arrays instead of a flat array of child documents.Example Entity:
Expected Document Fields:
Actual Document Fields:
Since the last child document sent to solr looks like it's field names are the array indices ('0' and '1' in this example), solr sends a 400 error saying "unknown field '0'".
Even though this seems to be a solarium bug, this bundle can easily work around it using the following
DocumentFactory::mapCollectionField()
function:What do you think, should this be fixed/changed on solarium's side? Or should this bundle take care of properly creating a flat child documents array?
I can send a pull request if needed.