...
- Size expectations or restrictions. It should decide specific implementation/module. How many items a module can process and how much time it takes the module to do it. For standard of FOLIO we can not demand it from everybody.
- Synchronous or asynchronous response. It depends on business model. As the main reason of batch API in FOLIO is save http traffic around Okapi.
- Complete or partial success / failure. It depends on implementation. In case of transactional approach it should be complete success/failure otherwise it should be partial success/failure
- Database transactions (specific to storage modules) It depends on requirements. For data-import it's necessary to determine which record is not saved during import large files and in this case it should be persisted as error (for further analysing)
- Streamed processing of records TBD It’s applicable for a document but what would we do in case of json entities? How to unmarshal bytes into entities
- Number of parallel database connections. If the maximum number of connections the database accepts is reached all modules and all tenants are blocked that need a new connection. See
Jira Legacy server System JIRA serverId 01505d01-b853-3c2e-90f1-ee9b165564fc key MODINVSTOR-330