ADAM 5.7.1 Release Notes

ADAM version 5.7.1



  • When upgrading from v5.7 to v5.7.1 and using unique identifier fields, the integrity of the
    unique identifier cache cannot be verified. For this reason, it is recommended to rebuild the
    unique identifier cache after the upgrade, as described in ADAM Installation Guide >
    Upgrading to ADAM 5.7.1 > Post-upgrade tasks.
  • When the unique identifier cache is being rebuilt and the process is interrupted (e.g. by a
    server restart), the cache will be corrupt and it will not be cleaned up automatically when
    doing another rebuild. The corrupt cache can be cleaned up manually in Elasticsearch to save
    disk space on the server.


  • 8883, 9308, 10145
    The ADAM cleaning routine completely stopped when an error occurred.
  • 9917
    Spaces loaded slowly if they contained facets with a large number of values.
  • 9992, 10051
    The Record Security Cache is no longer used during Enterprise search synchronization and
    reindexing, because it caused performance problems.
    Cleaning of the change history table is done only if the ADAM Server cleaning target is set to
    Only one cleaning of the change history can be executed at a time and all other incoming
    requests during execution will be skipped.
    SQL Query of the ADAM database view getFieldsValuesOfRecordContent_Required was
    modified to use INNER JOIN instead of INNER HASH JOIN.
    Cleaning of the change history table is now performed in batches of 2000 entries until all
    required entries are removed, instead of deleting all entries at once.
  • 10068
    An exception could occur when upgrading an Azure SQL database.
  • 10069
    The commands DisableChangeTracking and EnableChangeTracking did not support Azure
    SQL databases.
  • 10075
    Creating products from custom web applications could lead to threading issues, causing
  • 10091
    With verbose logging enabled, the building of unique identifiers failed because of a locking
  • 10143
    The Synchronization Service stopped running after a deadlock.
    A maximum of three automatic retries will now be performed in order to automatically
    recover from an error during the processing of changes (errors in general, not just
    deadlocks). On every retry attempt, a proper warning message is logged and an email with
    the same warning message is sent out . On the fourth attempt, the system will behave as
    before, sending out an error email and enabling Retry/Ignore buttons on the Enterprise
    Search Configuration guide page.
  • 10150
    An error could occur when using a code reference in a field's default value, in combination
    with the edit records page in Assets.
  • When upgrading ADAM, the setting .registeredCatalogActions was not properly updated,
    and did not include the CreateMovieStills catalog action.
  • Record Action menu items did not use the name property when no label was set and no
    name property translation was available.
  • Deleting a record also deleted similar identifiers in the unique identifiers cache.
  • Records with more than 10 unique identifiers were not cleaned up properly when deleted,
    causing potential duplicate mismatches.
  • Deleting a record/classification removed entries from the unique cache, but did not remove
    lookup entries for those deleted items.
  • Field values were only included in the unique identifier index when creating a new index.
    When updating a field in ADAM, the field values were removed from that index.
  • Duplicate values in the unique key cache caused inconsistent lookup entries in Elastic Search.
  • The log message was not clear for users when reindexing unique identifiers.

Was this article helpful?

0 out of 0 found this helpful