https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42835 --- Comment #79 from Luis Bataller <luis.bataller@xercode.es> --- (In reply to David Cook from comment #78)
Question... what do these 2 options have in common and what do they not have in common in terms of code?
Would it be possible to incorporate both options into Koha on an experimental basis?
--
On other bug reports and on Mattermost, I've been advocating for a design approach that embraces modularity more, so that we can more easily swap out modules.
As a community, we probably don't have the resources to support both, but if we design an internal API that allows us to use different modules, it will allow for easier innovations in the short-erm, which should also help with decision making for the longer term.
We could also end up choosing one as the community default, while a support company could choose the other option, and support it themselves.
I think there's some interesting possibilities here...
I think it's complex, but feasible. We could create two search subclasses for Elasticsearch: Koha::SearchEngine::ElasticsearchNested and Koha::SearchEngine::ElasticsearchParentChild. But I think the main challenge lies in the definitions (mappings, facets, sort fields, etc.) and in handling item updates that shouldn't trigger a reindex of the parent document. -- You are receiving this mail because: You are watching all bug changes.