[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 #108 from David Gustafsson <glasklas at gmail.com> ---
(In reply to Ere Maijala from comment #106)
> > Why? This is the behavior we had before. In my opinion, the point here is
> > not to discuss 
> > how we should format data for elasticsearch but make indexing process
> > faster. So, the first 
> > step is to have at least the same feature/data with koha-specific code we
> > had with Catmendu libraries and, once
> > we are done, check if we already have time saving.
> 
> I don't think the two can be separate. If the indexing method doesn't allow
> something that's clearly needed, any optimization of the indexing code needs
> to take it into account. Alex's comment #83 also implies that concatenation
> did work with Catmandu, and even if it didn't, it would have been easy to
> tweak the rules to fix it.
> 
> Your version of indexing would be faster than Catmandu even if subfields in
> a single field would be processed in rule order. But if all this becomes too
> complicated, I think it would be better to put any optimization on the back
> burner and work on the current code instead to fix its issues. E.g. I can
> easily resurrect the previous patch in bug 20244 for several improvements.

At took a look at it and it seams to be quite easily fixed with the optimized
indexing. I think you join all the subfields in your patch, but think can post
a patch by tomorrow (or the next day) where only some (defined in mappings)
subfields can be joins, without much increased complexity or impact on
performance.

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