[Koha-bugs] [Bug 19893] Alternative optimized indexing for Elasticsearch

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19893

--- Comment #97 from David Gustafsson <glasklas at gmail.com> ---
(In reply to David Gustafsson from comment #95)
> (In reply to Ere Maijala from comment #91)
> > If the fields don't belong together, you can always define them alone as is
> > currently done in many cases. It's just that you should also be able to say
> > that you want 245ab as a whole.
> 
> Sure, I can buy that. But that is not the way the mappings are currently
> defined in most places. For example Personal-name is mapped to
> "100abcdefghjklmnopqrstvxyz" and would have to be split up into one mapping
> for each subfield, like 100a, 100b, 100c, 100d etc, or all the information
> will be join into a string that does not make much sense. This will make
> search behavior harder to predict, potentially cause unexpected
> exact/proximity matches and thus more difficult to optimize.

I just realized that splitting up the fields would not make any difference with
the Koha-specific implementation, it makes no distinction if subfield mappings
are defined together in one mapping or separately. I would guess that it would
be much more efficient to introduce concaternation as an exception, with
special syntax (as there appears to be only a few mappings that have use for
it), and keep default behavior as it is.

-- 
You are receiving this mail because:
You are watching all bug changes.