Child pages
  • SUMMA Storage API Implementations for DOMS * (Thomas)
Skip to end of metadata
Go to start of metadata


The SUMMA Storage API Implementation (SSAI) is a piece shim code that enables the two systems to communicate.

The SUMMA interface is implemented SSAI gets the best semantically equivalently reply.

SUMMA Storage Architecture description

DOMS Readable Storage

The DOMSReadableStorage publishes the following methods:

Public Methods in DOMSReadableStorage objects
long getModificationTime(String summaBaseID)

long getRecordsModifiedAfter(long timeStamp, String summaBaseID, QueryOptions options)

List<Record> next(long iteratorKey, int maxRecords)

Record next(long iteratorKey)

Record getRecord(String summaRecordID, QueryOptions options)

List<Record> getRecords(List<String> summaRecordIDs, QueryOptions options)

Quoting the SUMMA Storage Architecture description regarding the metadata in SUMMA, in this module represented as a QueryOptions objects:

In addition to the raw record content the Storage attaches the following metadata to each record:

  • Base: A string signifying the origin of the record. For instance we use horizon for records originating from our Horizon ILS and oai for records harvested by our OAI-PMH harvester.
  • Creation time: A timestamp for when the record was first created in the storage
  • Modification time: Timestamp for when the record was last changed. For new records this equals the creation time
  • Parent records: A list of parent records. This can be either related to multivolume handling or FRBR
  • Child records: A list of child records. This can be either related to multivolume handling or FRBR
  • Deletion flag: Whether the record is marked as deleted. We never actually delete anything from the storage. We simply mark records as deleted
  • Indexable flag: Whether or not the record should be indexed
  • Custom meta tags: And additional map of key/value pairs. These can not be queried efficiently, but can be read once you are holding the actual record

Storing records externally, instead of directly in the Lucene indexes, provides for smaller indexes and more flexibility in a distributed environment. This also allows for the access to data to be independent of the underlying storage system. So far, Statsbiblioteket has used 4 different systems for Storage:

  • No labels