Goals
- Determine complexity of allowing for configuration of 001 generation (prefix + starting value)
- Adding the ability to select the desired authority source file at point of creation of new record (so the system would know how to generate the 001 per the configuration)
Approach
- Create new endpoint to retrieve HRID by authority file id
- Implement sequence number generation mechanism for authority local files
- On the UI user will select file name. And before creation UI should put to 001 field value from the HRID endpoint.
Tickets
Overview | Approach | Module | Story Points | Jira ticket |
---|---|---|---|---|
Validation for authority local files |
| mod-inventory-storage | 3 sp | |
APPROVED Implement sequence number generation mechanism for authority local files (Sequences Approach) |
| mod-inventory-storage | 5 sp |
|
DECLINED Implement sequence number generation mechanism for authority local files (Table with counter Approach) |
| mod-inventory-storage | 5 sp | |
Authority file id validation |
| mod-quick-marc | 2 sp |
|
Local authority file selection |
| ui-inventory |
|
Ability to store authority local files
Settings application UI preview:
Endpoints:
POST: /authority-source-files/{id}/hrid
Description: Endpoint returns current hrid value and increment it.
POST: /authority-source-files
New query parameter: startNumber (default = 1)
Sequence number generation mechanism for authority local files
Sequences Approach
There is a similar approach that works already in the mod-inventory-storage. It generates Hrid numbers for Instances, Holdings, and Item records, and can be configured from UI (Settings → Inventory → Hrid handling);
The problem here is that we will create new sequences in Runtime for each new authority file. (format: "hrid_authority_local_file_{prefix}_seq")
PROS | CONS |
---|---|
Auto increment | Separate sequence should be created for each authority file |
Atomic transaction. Safety works with asynchronous work |
Table with counter Approach
New table should be presented
To work with table it's better to use SERIALIZABLE Isolation:
@Transactional(isolation = Isolation.SERIALIZABLE)
PROS | CONS |
---|---|
One table for all authority files | All work with select and increment should be done manually. |
Harder work with transactions. All transactions should be fulfilled in SERIALIZABLE Isolation level. So it can reduce performance |
Select local authority file on the UI
- User should select local file for 001 field
- We also need to warn the user that field 001 may be overwritten by field 010.
Q/A section
Question | Status | Answer | Notes |
---|---|---|---|
How many files can be per one tenant? Do we expect millions of files? Can we restrict amount of authority files per tenant? | OPEN | We can likely expect less than 10 local authority files to be created. Typically, records are created for local files for use cases such as:
| |
Do we expect authority records matching with local authority file during DI process? | OPEN | Yes, it is possible for the library to want to update an existing local authority record via DI and would need to match on the existing file. |