Summary: | compare-es-to-db tool should offer a mode to reconcile differences | ||
---|---|---|---|
Product: | Koha | Reporter: | Liz Rea <wizzyrea> |
Component: | Command-line Utilities | Assignee: | Bugs List <koha-bugs> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P3 | CC: | blawlor, dcook, flyingendpaper, george, jonathan.druart, koha, lisette, robin, valerie |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
URL: | https://bywatersolutions.com/crowdsourcing/es-discrepancies | ||
Change sponsored?: | Seeking sponsor | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: |
Description
Liz Rea
2024-03-19 21:05:02 UTC
This would be valuable for libraries--not only be able to see what the problem is but also have a first-line strategy for resolving it. I like this idea. When we were first getting started with Elasticsearch with Koha, we were having lots of issues, so we had to write to write a script to help fix up the discrepancies. But it's difficult to do well. I think we need to start storing a timestamp in the Elasticsearch document, so that it can be compared against the biblio_metadata and items tables. If the timestamp for the bib or the item is greater than that of the ES document, then you could schedule a re-index (or maybe do a synchronous index since it's a CLI tool) for that particular record. Fortunately, we've managed to iron out the difficulties we were having, so this has been less of a pressing issue for us, but I still think it's a good idea for sure. The ES indexing can go wrong so easily, and it's currently so hard to repair without a full re-index :/. Good idea |