Versions Compared

Old Version 22

changes.mady.by.user Kalibek Turgumbayev

Saved on

compared with

New Version 23

changes.mady.by.user Kalibek Turgumbayev

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Option

Description

Pros & Cons

1

RDBMS

The audit database should persist a snapshot of the entity. The queries are made mostly by the entity's unique identifier. Thus partitioning by UUID and subpartitioning by date ranges can be applied to audit tables

Pros:

  • allows flexible access to versioning data

Cons:

  • limited scaling options

  • negative impact on Postgres that is used by all others modules

2

Object Storage

AWS S3-like storage can be used to persist snapshots because audit events can be stored as plain-text (JSON) documents

Pros:

  • allows scaling almost indefinitely

Cons:

  • requires an additional solution for complex queries

  • might cause high costs for storage bc of a large amount of operations on small files

2. Version history display: This should be done on demand comparing each consecutive snapshot of the entity to the previous

3. Changes to be tracked:

  • Changes in entity fields

  • Changes related to an update of the parent entity, e.g. holding update cascades to updates in items’ effective shelving order

  • Changes in metadata should be ignored

Key implementation aspects:

  1. The Kafka default delivery semantics is “AT_LEAST_ONCE”. Ensure that domain events have their unique identifiers to be able to handle consuming messages in an idempotent manner

  2. Add new consumers in mod-audit to inventory domain events.

  3. mod-audit should support the following configurations on the tenant level:

    1. Retention period in years (with default value - 0 for indefinite retention)

    2. Anonymizing flag that indicates whether the records in the database should be anonymized before persistence to the database.

  4. mod-audit should have the following scheduled jobs:

    1. Daily: to remove records that exceed the retention period

    2. Monthly: to create subpartitions for audit tables

  5. Persist audit events in an event storage. A single table in DB per entity type with partitioning by UUID (hash) and subpartitioning by date range.

  6. Create REST API
    4. to provide information on a list of changes related to a particular entity
    5. to provide detailed information on the particular change - this API should use the Object diff library to return a verbose description of the difference between current and previous snapshots of the entity

...

Risk

Description

Probability

Impact

Mitigation

1

Long period for audit records retention

The number of records could overwhelm the capability of the Postgres database both from a computational point of view and cost

High

High

Introduce separate storage for audit-events

2

Cascade Updates will create redundant copies in the audit log

The update to holdings causes updates to all related items. Some holdings may contain ~15000 records

High

Medium

Collapse or filter out events that only change the parent entity

3

Some flows could update inventory entities without using the Domain-events mechanism

With different capabilities of the system including UI, data import, bulk edit, etc some of the flows might skip sending Domain events and/or edit entities directly

Low

Medium

List those cases and add domain events to flows that has no this capability

4

Linked data

The flow and integration with inventory are not clear for the BIBFRAME format

Low

Low

Adjust BIBFRAME flow to follow the proposed solution for other inventory entities

...

Question

Answer

Comment

1

Should failure in sending audit message block the create/update/delete operation?

Hey Kalibek Turgumbayev - what happens today when an update is made and the create/update date and time stamp is not updated?

The question is related to transactional outbox pattern implementation

2

What would be the period of retention for Audit records?

Dennis Bridges has this requirement come up for you with respect to Acq’s change tracker?

The storage options depend on this question:

  • Postgres for ~ 1-3year

  • Postrgres with Partitioning by UUID 5-15 years

  • NoSQL options for 20+ years

3

In what form should we show the changes to non-marc fields (e.g. staffSuppress, administrative Notes, etc.) in MARC instances?

Kalibek Turgumbayev - I am unsure I understand this question. Can you review this mockup of how to display updates made to a FOLIO instance record?

Instance with source FOLIO or MARC from inventory is a separate object than SRS record and should be tracked separately

4

If only the order of fields in a MARC record is changed, should it be logged?

Kalibek Turgumbayev - Good question - I need to ask users but unless it is a significant to implement, answer is Yes.

Dennis Bridges has this requirement come up for you with respect to Acq’s change tracker?

5

Do we have scenarios where the audit log is exported in batches for some period of dates?

It is possible that a library may want to do so but I do not think it is a requirement for Sunflower. Dennis Bridges has this requirement come up for you with respect to Acq’s change tracker?

If the solution uses Postgres with partitioning by entity key, such exports would cause significant performance issues.

6

Do we need to have remapping or other technical updates as auditable events?

Not for Sunflower

We might need a list of actions leading to an event in the audit log.

7

Can we show only the last 20 records (last 3 months)?

Yes. Older records can be fetched with “see more” button and alert that it can take time.

Display of the whole history of the entity will impact performance negatively.

8

What should be tracked with BIBFRAME? Should we track the original BIBFRAME record or related MARC records is enough.

For Sunflower only track related MARC records.

  1. Acquisition event log - data retention period is 20 years

  2. Transactional outbox pattern

  3. Orders Event Log

  4. Javers - Java object diff library