Bug 23630: Do not remove field 999 in Elasticsearch indexing
authorFridolin Somers <fridolin.somers@biblibre.com>
Thu, 19 Sep 2019 14:55:51 +0000 (16:55 +0200)
committerFridolin Somers <fridolin.somers@biblibre.com>
Fri, 8 Nov 2019 15:50:51 +0000 (16:50 +0100)
commit4077a6faa98a8fe269c384eac8c7de31eedfc5ea
tree9adc0c60d06a3401b2ff204ad7458cadc80e5bfd
parent79f4870bd9d087316c4859e9f20e3f68f592649e
Bug 23630: Do not remove field 999 in Elasticsearch indexing

Elasticsearch indexing uses 999$c to store record id by deleting the all field first !
So you can not store anything in field 999, even in UNIMARC and even in authorities records.

Looks like it is quick fix code added to start Elasticsearch use.

This behavior is disturbing and very strange for UNIMARC flavour.

This patch corrects by defining record ids mandatory in Koha::SearchEngine::Elasticsearch::Indexer::update_index().
This ids array is actually always given (except in UT).
I think it is useless to allow adding a record without its id.

Test plan :
1) Use Elasticsearch as SearchEngine
2) Create a subfield 999$z in default framework
3) Create a record with default framework
4) Enter a random string (never used in catalog) like "tototata" in 999$z
5) In Search engine configuration, define search field "subject" for 999$z
6) Rebuild record : misc/search_tools/rebuild_elasticsearch.pl -b -bn <biblionumber> -v
7) Search for the random string => You get a result
8) Optionnaly look at records in ES : <es server>:9200/<es index name>/data/<biblionumber>

Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
(cherry picked from commit fb083813a8237691f0b9d419d826fdea58096cd4)
Signed-off-by: Fridolin Somers <fridolin.somers@biblibre.com>
Koha/SearchEngine/Elasticsearch.pm
Koha/SearchEngine/Elasticsearch/Indexer.pm
t/db_dependent/Koha/SearchEngine/Elasticsearch/Indexer.t