[OPEN-ILS-DEV] Fastest way to load titles after catalog search (via OSRF)?

[Bill Erickson]

Hi Ken,

On Sat, Sep 17, 2016 at 2:44 PM, Ken Cox <kenstir at gmail.com> wrote:

> Is there a way to load the basic metadata (title and author) about
> multiple catalog items in one round-trip?
>
> Currently after a search the Android app is making the following OSRF
> calls for each item found:
>
>    - service=open-ils.search & method=
>    *open-ils.search.biblio.record.mods_slim.retrieve* & param=*item_id*
>
> There is a batch version of this API:

open-ils.search.biblio.record.mods_slim.batch.retrieve[.atomic] [id1, id2,
id3, ...]

Are you using the stock OSRF Java HTTP library -- the GatewayRequest
class?  I ask because it does not support streaming API calls.  (I'm not
seeing any stock Java libs that support streaming, no TranslatorRequest or
WebsocketRequest classes).  This makes the batch API's somewhat less
appealing, since you have to wait for the entire result set to return
before you have any results to work with.  In some cases, though, it can
still be an improvement.

In the future, we need a Translator and/or Websocket client for the Java
libs and we need to finish https://bugs.launchpad.net/evergreen/+bug/1251394
(metabib display fields), which support returning pre-compiled metadata via
(presumably) the much faster PCRUD API.


>    -
>    - service=open-ils.pcrud & method=*open-ils.pcrud.retrieve.mra*
>    & param=%22auth_token%22 & param=*item_id*
>
> For this one, you could probably get away with a single batch API call:

open-ils.pcrud.search.mra.atomic {id : [id1, id2, id3...]}

The result set for this call is relatively small and should be quick to
build on the server, so a single call/response might be faster than a
call/response per record.

See also the "mraf" class, where you can further limit by "type", plus its
result data is much easier to parse.

-b
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20160919/529f8c75/attachment.html>