https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19893
--- Comment #108 from David Gustafsson <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
