https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=42508 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #8 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Hi all, I'm going to submit what I've implemented for ES patron indexing and searching. It is a drop-in replacement for the current search page with the same functionality, plus the infrastructure required to keep the index up to date. Much of the work is relevant for an SQL-based implementation too, and I'll explore that next. I would like to mention that the Koha dev community has not endorsed migrating logic from the application layer into database triggers in the past (see bug 33905), and I believe the reasons still hold. Triggers make the denormalized search table always-on and DB-local, but they also move patron business logic into opaque synchronous database side effects. For high-traffic circulation systems, that can increase write-path latency, amplify locking, introduce deadlocks, and make bulk updates/imports harder to reason about. I prefer an explicit async indexing path: patron-affecting business actions enqueue indexing jobs, and a full rebuild tool guarantees recoverability. That said, I'll talk to ByWater about investing some time in trying the denormalized table approach with the framework I've already built. If the denormalized table is maintained by the same async indexing framework, rather than triggers, it avoids most of the operational concerns around hidden synchronous database side effects. At that point, the tradeoff becomes less about safety and more about search capability: SQL materialization is simpler to deploy, while Elasticsearch provides a more capable search backend (ranking, fuzziness, analyzers, partial matching, etc). -- You are receiving this mail because: You are watching all bug changes.