Page Comparison

Tickets:

• Jira Legacy
  server FOLIO Issue TrackerSystem JIRA serverId 6ccf3fe401505d01-3301b853-368a3c2e-983e90f1-20c466b11a49ee9b165564fc key CIRC-573

• Jira Legacy
  server FOLIO Issue TrackerSystem JIRA serverId 6ccf3fe401505d01-3301b853-368a3c2e-983e90f1-20c466b11a49ee9b165564fc key UICIRC-736

Batch API

Existing API endpoints to provide batch API alternative of:

...

This endpoint would follow a similar design structure as to those described here:

• Jira Legacy
  server FOLIO Issue TrackerSystem JIRA serverId 6ccf3fe401505d01-3301b853-368a3c2e-983e90f1-20c466b11a49ee9b165564fc key FOLIO-2050

• https://issues.folio.org/secure/attachment/20079/Possible%20batch%20api%20workflow.png

References:

• Jira Legacy
  server FOLIO Issue TrackerSystem JIRA serverId 6ccf3fe401505d01-3301b853-368a3c2e-983e90f1-20c466b11a49ee9b165564fc key MODUIMP-57

• Jira Legacy
  server FOLIO Issue TrackerSystem JIRA serverId 6ccf3fe401505d01-3301b853-368a3c2e-983e90f1-20c466b11a49ee9b165564fc key MODINVSTOR-478

• Jira Legacy
  server FOLIO Issue TrackerSystem JIRA serverId 6ccf3fe401505d01-3301b853-368a3c2e-983e90f1-20c466b11a49ee9b165564fc key MODINVSTOR-353

• Jira Legacy
  server FOLIO Issue TrackerSystem JIRA serverId 6ccf3fe401505d01-3301b853-368a3c2e-983e90f1-20c466b11a49ee9b165564fc key RMB-505

• Jira Legacy
  server FOLIO Issue TrackerSystem JIRA serverId 6ccf3fe401505d01-3301b853-368a3c2e-983e90f1-20c466b11a49ee9b165564fc key FOLIO-1156

• https://s3.amazonaws.com/foliodocs/api/mod-inventory-storage/instance-storage-batch.html
• https://s3.amazonaws.com/foliodocs/api/mod-inventory-storage/instance-sync.html
• https://www.citusdata.com/blog/2017/11/08/faster-bulk-loading-in-postgresql-with-copy/
• https://stackoverflow.com/questions/46715354/how-does-copy-work-and-why-is-it-so-much-faster-than-insert
• How to design batch API (General recommendations)
• https://www.postgresql.org/docs/12/sql-values.html

...

The existing renewal process is too slow. However, having a batch perform one operation at a time has also proven problematic. The suggested design is to have a batch process renewals and when it has accrued a designated number of successful renewals, submit them to the storage module as a sub-batch.
The business logic can perform a pre-process where it checks to see if any of the renewals would fail for business logic reasons. Hold all renewals that pass the business logic test and then when the sub-batch size is reached make a request to the storage module using the sub-batch. This is potentially problematic in that if something fails in the sub-batch the entire sub-batch might be considered a failure. If this is undesired then a sub-batch size of 1 must be used. The size of the sub-batch will need to be determined, and could be configurable or a property specified in the request if desired. This approach would require a bulk update endpoint to be available from the storage module.

...

UPDATE table AS t SET
  field1 = v.field1,
  field2 = v.field2
FROM (values
  (1, 'field1 row1', 'field2 row1'),
  (2, 'field1 row2', 'field2 row2')
) AS v(id, field1, field2)
WHERE v.id = u.id;

Ticket