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
Currently normalizers are called with a special searchableArray format. However this is still not enough, since you can only determine if the data is serialized for Algolia or for different purpose (e.g. API-Platform). There's no way (or I don't see it) to support such structure:
[books_index] (e.g. for autocomplete)
| - book1
| | - title: Foo Bar
| | - author: John Doe
| \ - readers: 124
\ - book2
| - title: Baz Bat
| - author: Josh A.
\ - readers: 222
[categories]
| - category1
| - name: Good Books
\ - promoted
| - book1
| | - title: Foo Bar
| \ - author: John Doe
\ - book2
| - title: Baz Bat
\ - author: Josh A.
This is a synthetic example, but the problem has a real business use-case. If you have collection of items you cannot get a basic version of an entity for collections and advanced version of the same entity for a separate index.
This is kind of related to #139, but I basically need to differentiate between nested objects and top level indexes.
Solutions
I see two ways of making this experience better - first is intermittent but very simple and second is advanced but flexible and easily extensible:
Pass index entity in context
normalize() receives $context array. In this array we can add class name of the currently processed index. With such construction normalize() method may look like:
(of course properly it should be a separate normalizer which delegates via composition etc but I skipped this for simplicity)
This can be added literally in 5 minutes (let me know - I can submit PR) by modifying SearchableEntity::getSearchableArray() to call $context['rootEntity'] = \get_class($this->entity).
Allow defining normalization groups
This is a proper solution for the problem. Currently there's a blanket searchable group passed. This is good when I want to decide what goes to search engine and what not, however I cannot have multiple groups depending on the index.
Implementing this will require plugging into SearchableEntity::getSearchableArray() and changing how configuration is parsed to get this extra list. All in all it doesn't seem like a lot more work.
Conclusion
RFC ;) Maybe I don't understand something, but I think in a current state what I need is not possible.
The text was updated successfully, but these errors were encountered:
kiler129
changed the title
Determine Index Affected On Normalization
Custom Serialization Groups & Access To Root Entity Class On Normalization
Feb 13, 2019
Description
Currently normalizers are called with a special
searchableArray
format. However this is still not enough, since you can only determine if the data is serialized for Algolia or for different purpose (e.g. API-Platform). There's no way (or I don't see it) to support such structure:This is a synthetic example, but the problem has a real business use-case. If you have collection of items you cannot get a basic version of an entity for collections and advanced version of the same entity for a separate index.
This is kind of related to #139, but I basically need to differentiate between nested objects and top level indexes.
Solutions
I see two ways of making this experience better - first is intermittent but very simple and second is advanced but flexible and easily extensible:
Pass index entity in context
normalize()
receives$context
array. In this array we can add class name of the currently processed index. With such constructionnormalize()
method may look like:(of course properly it should be a separate normalizer which delegates via composition etc but I skipped this for simplicity)
This can be added literally in 5 minutes (let me know - I can submit PR) by modifying
SearchableEntity::getSearchableArray()
to call$context['rootEntity'] = \get_class($this->entity)
.Allow defining normalization groups
This is a proper solution for the problem. Currently there's a blanket
searchable
group passed. This is good when I want to decide what goes to search engine and what not, however I cannot have multiple groups depending on the index.This could be defined as follow:
Implementing this will require plugging into
SearchableEntity::getSearchableArray()
and changing how configuration is parsed to get this extra list. All in all it doesn't seem like a lot more work.Conclusion
RFC ;) Maybe I don't understand something, but I think in a current state what I need is not possible.
The text was updated successfully, but these errors were encountered: