UXPROD-5802 - Umbrellaleaf - Bulk Edit Performance Improvements
The idea is to switch entity retrieval to use FQM. In this approach, the backend constructs a query for the required identifiers, submits it to FQM, and waits for the results. Once the results are ready, Bulk Ops downloads them and starts processing (persisting them locally for further handling). Therefore, FQM must support passing the required identifier types in the IN operator.
The whole list of Bulk Ops identifier types expected to be integrated with FQM using FQM IN- operator:
Entity | Identifier types | Note |
|---|---|---|
Instance | Instance UUIDs Instance HRIDs | integrated IN-supported |
Holdings record | Holdings UUIDs Holdings HRIDs Instance HRIDs Item barcodes | integrated IN-supported IN-supported IN-not supported |
Item | Item barcodes Item UUIDs Item HRIDs Item former identifiers Item accession numbers Holdings UUIDs | IN-supported integrated IN-supported IN-supported IN-supported IN-supported |
User | User barcodes User UUIDs External IDs Usernames | IN-supported integrated IN-supported IN-supported |
The IN-operator in FQM allows querying entities by all identifier types except for one case: Holdings Record - Item Barcodes (support needs to be added on the FQM side). This enables native integration with FQM using asynchronous calls POST /query and GET /query/{id}.
non-ECS case
ECS case
Assumptions
The implementation for UUIDs (instances, holdings, items, users) must remain unchanged and continue to use the synchronous FQM /contents call. Asynchronous flows should be implemented for all identifiers other than UUIDs.
Questions
Limitations of query size to include large number of identifiers in the IN-operator? The answer to this question determines whether query chunking is required, since the current implementation of FqmFetcher only retrieves results but does not submit the query.