Bug 15054

Summary: Get items from database instead of search engine in search results
Product: Koha Reporter: Fridolin Somers <fridolin.somers>
Component: SearchingAssignee: Fridolin Somers <fridolin.somers>
Status: ASSIGNED --- QA Contact: Testopia <testopia>
Severity: enhancement    
Priority: P5 - low CC: dcook, hector.hecaxmmx
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33568
Change sponsored?: --- Patch complexity: Small patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: TEMP get items from database
Bug 15054 - Get items from database instead of search engine in search results

Description Fridolin Somers 2015-10-23 15:08:58 UTC
Since OPAC uses the XSLT, the items displayed in search results does not come from search engine results anymore (see C4::XSLT::buildKohaItemsNamespace), they come from database table items.
At intranet, the search results page, even when XSLT is used, displays items in left column and they come from search engine result.

This enh proposes to get items from database.
The big advantage is that item status display does not relay on indexing anymore. When checking in or out, the effect in search results is instantaneous, same for item defined as lost, damaged, ...
Comment 1 Fridolin Somers 2015-10-23 15:16:13 UTC Comment hidden (obsolete)
Comment 2 Fridolin Somers 2015-10-23 15:20:35 UTC
Created attachment 43880 [details] [review]
Bug 15054 - Get items from database instead of search engine in search results

Since OPAC uses the XSLT, the items displayed in search results does not come from search engine results anymore (see C4::XSLT::buildKohaItemsNamespace), they come from database table items.
At intranet, the search results page, even when XSLT is used, displays items in left column and they come from search engine result.

This enh proposes to get items from database.
The big advantage is that item status display does not relay on indexing anymore. When checking in or out, the effect in search results is instantaneous, same for item defined as lost, damaged, ...

Test plan :
- Disable zebraqueue indexing (rebuild_zebra -z)
- Perform a search
- Choose a result with an item available for loan
- Perform a checkout on this item
- Re-perform a search
=> Without patch you see the item still available
=> With patch you see the item on loan
- Test also with checkin
Comment 3 Fridolin Somers 2015-10-23 15:22:43 UTC
I've run some tests : 
Search with 100 results per page, with and without the patch.
I do not see a significant performance difference.
Comment 4 Héctor Eduardo Castro Avalos 2016-02-02 20:16:39 UTC
Hi Fridolin

Sorry but fail in Merge step, could you please rebase/fix, I think IMHO your patch is a good solution. The problem you describe is very annoying.

Applying: Bug 15054 - Get items from database instead of search engine in search results
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging C4/Search.pm
CONFLICT (content): Merge conflict in C4/Search.pm
Failed to merge in the changes.
Patch failed at 0001 Bug 15054 - Get items from database instead of search engine in search results
When you have resolved this problem run "git bz apply --continue".
If you would prefer to skip this patch, instead run "git bz apply --skip".
To restore the original branch and stop patching run "git bz apply --abort".
Comment 5 Fridolin Somers 2021-02-22 15:38:12 UTC
Now with Elasticsearch, this can be very useful
Comment 6 Fridolin Somers 2021-02-22 15:38:39 UTC
I'll try to rebase
Comment 7 David Cook 2022-09-09 03:28:17 UTC
This would resolve the issue I had with https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15187
Comment 8 David Cook 2022-09-09 03:28:47 UTC
I think very outdated now though and I wonder what performance implications there would be...
Comment 9 Katrin Fischer 2023-08-27 14:08:35 UTC
(In reply to David Cook from comment #8)
> I think very outdated now though and I wonder what performance implications
> there would be...

Frido, do you think this one could be closed or is it something we should follow-up on?
Comment 10 Fridolin Somers 2023-08-29 07:05:51 UTC
I'd like to keep it open ;)
Comment 11 David Cook 2023-08-29 23:07:09 UTC
This could make sense too in terms of showing only a subset of items. I've actually been thinking for a while how we should have a more scalable display of item/holdings information in search results (and detail page)...
Comment 12 Katrin Fischer 2023-09-04 19:40:37 UTC
(In reply to David Cook from comment #11)
> This could make sense too in terms of showing only a subset of items. I've
> actually been thinking for a while how we should have a more scalable
> display of item/holdings information in search results (and detail page)...

Did you see bug 33568?
Comment 13 David Cook 2023-09-04 23:04:02 UTC
(In reply to Katrin Fischer from comment #12)
> (In reply to David Cook from comment #11)
> > This could make sense too in terms of showing only a subset of items. I've
> > actually been thinking for a while how we should have a more scalable
> > display of item/holdings information in search results (and detail page)...
> 
> Did you see bug 33568?

Yep :)