Context - Prior to Sunflower

updates to instance, holdings, and items were processed regardless of whether the incoming data actually reflected a change from the existing database records. For example, when a field that doesn't map to the FOLIO instance is changed in the SRS record, the updates are processed, even when the FOLIO instance itself wasn't updated (and vice versa). This unnecessary execution of update operations:

• consumes excessive system resources

• increases the risk of unintended data conflicts

• reduces overall efficiency

Sunflower

In https://folio-org.atlassian.net/browse/MODINVSTOR-1363 , a mechanism was implemented to determine when changes to a record actually reflect a change from the existing database records and if so, the system will proceed with database modifications. With this logic, unnecessary actions such as events to other modules (currently nine), indexing data, and creating audit logs, will no longer be performed if a change is not detected in a record. The result is that in some scenarios, the update date of the SRS record and that of the FOLIO record will not match.

Though this mechanism reduces redundant updates for database operations, the implementation impacts select workflows, such as:

• Using the update data in the record metadata to trigger changes to discovery layers

  • With the optimization enabled, the update date will only be updated if the field of corresponding records updates the field of the other record (SRS --> FOLIO, FOLIO --> SRS). However, some workflows require that any change to a record representing the bibliographic entity reflects an update so that discovery systems can reflect all changes, regardless of record source (SRS vs FOLIO). Without this consistent update date, some changes to the bibliographic record will not be reflected in the discovery layer (https://folio-org.atlassian.net/browse/MODSOURCE-972 )

• Data Import https://folio-org.atlassian.net/browse/MODDATAIMP-1290

  • With this optimization enabled, Data import logs show records as updated

Feature flag

Because of the various use cases surrounding the update date in the metadata, we need to add a feature flag to enable or disable the optimization mechanism. This functionality is currently in refinement and captured in this story https://folio-org.atlassian.net/browse/MODINVSTOR-1577