You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
useBecklyn\SearchBundle\MappingasSearch;
@Search\Item()
class A {}
@Search\Item()
class B extends A {}
@Search\Item()
class C extends A {}
@Search\Item()
class D extends B {}
To retrieve all search results one would have the following options:
$searchResults = $searchClient->search($query, $language);
// Option a: Work with the Entity Results Lists$allResults = $searchResults->getEntityResultLists();
// Option b: Retrieve each individual result$aResults = $searchResult->getResult(A::class);
$bResults = $searchResult->getResult(B::class);
$cResults = $searchResult->getResult(C::class);
$dResults = $searchResult->getResult(D::class);
The downside for the a approach is that you have to do the grouping yourself. Passing down the entity results list directly into the template can also get quite messy real fast since you need to have (probably multiple) places where you keep track of your hierarchy and which you probably want grouped together.
Approach b is more explicit and therefore better per se, though the pain points start when you add a new class E extends A and forget to add it to the various places where you're explicitly retrieving results for the given data structure.
The proposals
Automatic data hierarchy analysis
One potential solution here would be to have a look at the entity's data hierarchy while indexing so one could easily do $allAResults = $searchResults->getResult(A::class) and retrieve results for A, B, C, D and in the future even E.
While this proposal may sound like a good and intuitive way to solve the problem, this would mean that indexing and outputting the results gets even more expensive and than it already is since we would have to search through the entity's hierarchy and then saving it alongside its metadata.
Tagging
The more promising solution here would be allowing the developer to logically group entities together by extending the @Search\Item to contain an $tags-Array.
The above data structure could then look like this:
@Search\Item("tags"={"a"})
class A {}
@Search\Item("tags"={"a", "b"})
class B extends A {}
@Search\Item("tags"={"a"})
class C extends A {}
@Search\Item("tags"={"a", "b"})
class D extends B {}
The SearchResult class would then need a new method like getTaggedResults(string) to fetch such results:
This would return me all relevant a-tagged Entities. This makes using the search bundle even future proof as I can easily add new classes with the same tag and my existing logic would automatically pick them up and return their results without me having to do anything:
@Search\Item("tags"={"a"})
class X {}
@Search\Item("tags"={"b"})class Y {}@Search\Item("tags"={"c"})
class Z {}
The text was updated successfully, but these errors were encountered:
The problem
Given the following data structure:
To retrieve all search results one would have the following options:
The downside for the
a
approach is that you have to do the grouping yourself. Passing down the entity results list directly into the template can also get quite messy real fast since you need to have (probably multiple) places where you keep track of your hierarchy and which you probably want grouped together.Approach
b
is more explicit and therefore better per se, though the pain points start when you add a newclass E extends A
and forget to add it to the various places where you're explicitly retrieving results for the given data structure.The proposals
Automatic data hierarchy analysis
One potential solution here would be to have a look at the entity's data hierarchy while indexing so one could easily do
$allAResults = $searchResults->getResult(A::class)
and retrieve results forA, B, C, D
and in the future evenE
.While this proposal may sound like a good and intuitive way to solve the problem, this would mean that indexing and outputting the results gets even more expensive and than it already is since we would have to search through the entity's hierarchy and then saving it alongside its metadata.
Tagging
The more promising solution here would be allowing the developer to logically group entities together by extending the
@Search\Item
to contain an$tags
-Array.The above data structure could then look like this:
The
SearchResult
class would then need a new method likegetTaggedResults(string)
to fetch such results:This would return me all relevant
a
-tagged Entities. This makes using the search bundle even future proof as I can easily add new classes with the same tag and my existing logic would automatically pick them up and return their results without me having to do anything:The text was updated successfully, but these errors were encountered: