[FOLIO-937] Design and implement "CODEX Instance" multiplexer module Created: 16/Nov/17  Updated: 12/Nov/18  Resolved: 22/Dec/17

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P3
Reporter: Jakub Skoczen Assignee: Adam Dickmeiss
Resolution: Done Votes: 0
Labels: alpha, core, sprint27, sprint28
Remaining Estimate: Not Specified
Time Spent: 7 hours
Original estimate: Not Specified

Issue links:
Duplicate
duplicates FOLIO-934 Plan and design Codex Search multiple... Closed
Relates
relates to MODCXMUX-2 First implementation of codex mux Closed
relates to FOLIO-933 CODEX Instance contract definition v1 Closed
relates to FOLIO-939 Implement codex mock module Closed
relates to OKAPI-418 Separate interfaces from module imple... Closed
Sprint:

 Description   

In FOLIO-933 Closed we are finalising CODEX Instance schema/interface for searching across local Inventory and eHoldings.

While FOLIO-933 Closed is still ongoing, we have enough to start looking at the multiplexer module.

Requirements
-------------------

  • merging data across 2 codex Instance endpoints (initially, eventaully N endpoints)
  • no blending and no de-duplication of results
  • sorted merge relying on backend sort capabilities to avoid retrieving complete result sets
  • automatic fetching of more records from backend endpoints as the user pages through multiplexed results

Interface
------------
We hope to retain the same instance schema as the backend endpoints. CQL used for searching, and depending on how we deal with ERM limitations, either a simple passthrough or query rewrite mechanism.

Implementation
--------------------

Time is of essence. The module first and foremost use case is to merge Instance data and as such it's okay to keep it specific to this particular schema, especially if it simplifies the implementation.

If it makes sense, we would like to utilize the "multiple" interface feature of Okapi. The multiplexer module would be the singleton implementator of this interface.

https://github.com/folio-org/raml/tree/master/examples/codex
https://github.com/folio-org/raml/tree/master/ramls/codex



 Comments   
Comment by Jakub Skoczen [ 16/Nov/17 ]

Adam Dickmeiss Heikki Levanto Guys, please look and discuss this issue and ping me if you have any question or want to chat. I'd like to make this a priority for one of you for next week. Thanks!

Comment by Heikki Levanto [ 21/Nov/17 ]

We can get pretty far without Okapi-418. It means we may have to repeat the interface in the ModuleDescriptors, but that is not very hard to do. It will be easy to change those to refer to a specifically defined InterfaceDescriptor when we get that far. No need to let that slow us down at this point.

Comment by Khalilah Gambrell [ 28/Nov/17 ]

Hey all - question
1. I conduct a search for Whale
2. I get 10 results from Inventory
3. I get 10 results from eHoldings
4. Results are sorted by Title
5. 18 out of 20 results have the exact same title of Whale
Question: If the title is same for 18 out of 20 total results, how do you determine sort order? Would the user see all inventory results with the exact same title of Whale followed by eHoldings results with the exact same title of Whale?

Comment by Adam Dickmeiss [ 07/Dec/17 ]

The sort order for identical sort keys is in target-order.. Ie the way that modules are returned from Okapi.. So it will "always" show instance 1 from first returned module and instance 2 from 2nd returned module if they have the same sort key.. Such as title. We don't merge them or anything like that.

Comment by Adam Dickmeiss [ 07/Dec/17 ]

In your exampe Khalilah Gambrell. .. Suppose 20 results have same title - 10 from each, then it would show 10 from first one (Inventory) and next 10 from eHoldings.. Again provided they all have exact same title.

Comment by Khalilah Gambrell [ 07/Dec/17 ]

Thanks Adam Dickmeiss

Comment by Adam Dickmeiss [ 22/Dec/17 ]

Closing now. From now one, new issues with specific improvements,, eg MODCXMUX-7 Closed

Generated at Thu Feb 08 23:09:25 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.