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.
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.
An exception could occur when upgrading an Azure SQL database.
The commands DisableChangeTracking and EnableChangeTracking did not support Azure
Creating products from custom web applications could lead to threading issues, causing
With verbose logging enabled, the building of unique identifiers failed because of a locking
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.
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