The return value of searches (documented for \Drupal\search_api\Query\QueryInterface::execute()
) is currently one huge array, which should of course be split up. We want a class for the result as a whole, and a class for each returned result (with methods for getting the ID, the datasource (and maybe the raw, datasource-specific ID?), the score, the original item, etc.). Also, of course, a method for adding/reading additional results data, where, e.g., facets could be returned.
Likewise, during indexing we extract the item data into the typical huge D7 arrays, with settings keys ($item[#something']
) used for passing the original object, datasource ID and item ID (and possibly other metadata later).
This should be switched to a proper OO implementation, using classed objects for each item, and for the fields contained within. The item object should have methods for retrieving the original object, datasource ID and item ID, as well as methods for getting/setting arbitrary metadata. Implementing Traversable
might also be a good idea.
We might also look at whether it makes sense for the item class (resp. its interface – both classes should of course also have interfaces) to inherit from ComplexDataInterface
, and the field class from TypedDataInterface
.
The question then is also whether both indexing and result items should use the same class.
Comments
Comment #1
BerdirIf we want to use the same classes, should we postpone it on #2252079: Switch to proper objects for extracted items?
Comment #2
das-peter CreditAttribution: das-peter commentedComment #4
das-peter CreditAttribution: das-peter commentedI'm not sure when I'm able to continue here - so unassigning me for now :|
Comment #5
drunken monkeyI hope I'll be able to finally implement this this week.
(Also, merging #2252079: Switch to proper objects for extracted items into this issue.)
Comment #7
drunken monkeyAlmost unbelievable, but I finally made it. Was quite a bit more than anticipated, but at least I managed to finish before the sprint …