MODQM-311 - Getting issue details... STATUS

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	New parameter 'startNumber' for authority source file creation is presented Implement AuthoritySourceFileHridManager with Validation: - (if source = 'local' then codes.size = 1) else throw exception - (if source = 'local' and startNumber = null) set startValue = 1 - prevent user to update "start with" after file creation	mod-inventory-storage	3 sp	MODINVSTOR-1049 - Getting issue details... STATUS
APPROVED Implement sequence number generation mechanism for authority local files (Sequences Approach)	New endpoint to catch-up authority current hrid information is presented Extend AuthoritySourceFileHridManager to work with sequences - Create sequence for authority local file after validation - Update sequence name for authority local file if prefix was updated - Drop sequence for authority local file after deletion Return hrid on request - Retrieve next value from localFile sequence - Format next value to NaturalId(HRID) format	mod-inventory-storage	5 sp	MODINVSTOR-1050 - Getting issue details... STATUS
DECLINED Implement sequence number generation mechanism for authority local files (Table with counter Approach)	New endpoint to catch-up authority current hrid information is presented New table to work with authority files HRID presented Extend AuthoritySourceFileHridManager to work with table - All transactions should be done with SERIALIZABLE isolation - On request return current hrid value and increment it. - Format value to NaturalId(HRID) format	mod-inventory-storage	5 sp
Authority file id validation	mod-quick-marc in scope of authority creation should convert 001 field value to UUID and retrieve available hrid for source file id. Replace 001 field value from authorityFileId to "prefix + hrid" If 001 value doesn't comply with UUID then skip it. And leave the original value	mod-quick-marc	2 sp	MODQM-322 - Getting issue details... STATUS
Local authority file selection	User should have the ability to look-up for local authority file (As permanent-location look-up for Holdings) UI should put authorityFileId to 001 field	ui-inventory		UXPROD-3910 - Getting issue details... STATUS

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.

Authority Source File HRID Example

{
    "id": "cb58492d-018e-442d-9ce3-35aabfc524aa",
    "prefix": "loc",
    "hrid": "000000001"
}

POST: /authority-source-files
New query parameter: startNumber (default = 1)

startNumber parameter schema

"startNumber": {
  "description": "The number from which to start generating HRIDs",
  "type": "integer",
  "minimum": 1,
  "maximum": 99999999999
}

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

hrid_authority_source_file

CREATE TABLE IF NOT EXISTS hrid_authority_source_file
(
  authorityFileId UUID NOT NULL,
  hridSeq         INT  NOT NULL,
  CONSTRAINT hrid_authority_source_file_pkey PRIMARY KEY (authorityFileId),
  CONSTRAINT hrid_authority_source_file_fkey FOREIGN KEY (authorityFileId)
    REFERENCES authority_source_file (id)
);

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
Do we expect authority records matching with local authority file during DI process?	OPEN

MODQM-311 Spike: Investigate feasibility of local authority source support