> ## Documentation Index
> Fetch the complete documentation index at: https://docs.activeviam.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Migration notes 5.10

# Migrate to 5.10

### Datastore

* `Primary` indexes are now called `Unique` indexes (All the rows in an index of this type must be unique).
* `TransactionManagerUtil.resetBranch` was moved in `ITransactionManager`.
* Rename `ARemoveUnknowKeyListener` to `ARemoveUnknownKeyListener` to fix typo.
* Move `NumaSelectorFromStoreDescription` from `com.qfs.desc` to `com.qfs.desc.impl` package.
* Move `ADefaultEpochPolicy` from `com.qfs.multiversion` to `com.qfs.multiversion.impl` package.
* Rename `ImmutableRecordList` to `ImmutableRecordBlock` to match the naming pattern used by sibling classes.

### ActivePivot

* Change the hierarchy builder: `hierarchyBuilder.factless().withStoreName(...)` was replaced by `hierarchyBuilder.fromStore(...)`. It cannot be called after `factless()` nor `notFactless()`.
* Rename `MultiVersionAxisHierarchy.FIELD_NAME_PROPERTY` to `MultiVersionAxisHierarchy.FIELD_EXPRESSION_PROPERTY`.

#### Copper

* All published Copper measure must now be named. Expressions like `Copper.sum("pnl").publish(context)` have to be replaced with `Copper.sum("pnl").withName("pnl.SUM").publish(context)`.
* `Copper.newSingleLevelHierarchy(...).from(CopperStoreField)` was replaced by `Copper.newHierarchy(...).fromField(CopperStoreField)`.
* `Copper.newSingleLevelHierarchy(...).from(CopperLevelValues)` was replaced by `Copper.newHierarchy(...).fromValues(CopperLevelValues)`.

#### Distribution

* The `JGroupsMessenger` has been removed. Now, ActivePivot relies on two messenger types, the `LocalMessenger` and the `NettyMessenger`. Note that the `NettyMessenger` still
  uses JGroups for member discovery and group membership. More details on this topic in [Distributed Messenger](../../../distributed/communication_flow#distributed-messenger)
* The property `NotificationMember#AWAIT_NOTIFICATIONS` has been renamed to `IDataClusterDefinition#AWAIT_NOTIFICATIONS_TIME`.

#### Functional Interfaces

The functional interfaces in package `com.qfs.func` have been moved and renamed.

| Old location                                 | New location                                       |
| -------------------------------------------- | -------------------------------------------------- |
| `com.qfs.func.IBiIntPredicate`               | `com.activeviam.util.function.BiIntPredicate`      |
| `com.qfs.func.IFloatUnaryOperator`           | `com.activeviam.util.function.FloatUnaryOperator`  |
| `com.qfs.func.IntBiFunction`                 | `com.activeviam.util.function.IntBiFunction`       |
| `com.qfs.func.ITriFunction`                  | `com.activeviam.util.function.TriFunction`         |
| `com.quartetfs.fwk.util.FloatBinaryOperator` | `com.activeviam.util.function.FloatBinaryOperator` |
| `com.qfs.func.IEither`                       | `com.activeviam.util.function.IEither`             |
| `com.qfs.func.IOptionalEither`               | `com.activeviam.util.function.IOptionalEither`     |
| `com.qfs.func.impl.Either`                   | `com.activeviam.util.function.impl.Either`         |
| `com.qfs.func.impl.OptionalEither`           | `com.activeviam.util.function.impl.OptionalEither` |

#### Query Results Context Value

The default behavior for `QueriesResultLimit` context value have changed from `QueriesResultLimit#withoutLimit()` to `QueriesResultLimit#defaultLimit()`
(the default transient and intermediate result limit amount to 100,000 and 1,000,000 point locations respectively). The default limits may appear low for certain projects,
in this case the configuration can be easily overridden. This is explained in the respective [documentation section](monitoring/monitoring-query-execution#setting-limits-for-query-results).

### ActiveViam Properties

* `activeviam.datastore.query.maxLookupsOnPrimary` was renamed `activeviam.datastore.query.maxLookupsOnUnique`.
* `ActiveViamProperty.MAX_LOOKUPS_ON_PRIMARY_INDEX` was renamed `ActiveViamProperty.MAX_LOOKUPS_ON_UNIQUE_INDEX`.

### Spring Configuration Changes

The ActivePivot Configuration does not automatically contain the `ContextValueFilter` bean anymore,
thus preventing conflicts with Spring Boot.

### Azure Cloud Source migration

The Azure Cloud Source has migrated its dependency to the Azure Blob Storage SDK from v8 to [v12](https://github.com/Azure/azure-sdk-for-java/tree/master/sdk/storage/azure-storage-blob).

> A migration guide from v8 to v12 can be found on the [Azure SDK repository](https://github.com/Azure/azure-sdk-for-java/blob/master/sdk/storage/azure-storage-blob/migrationGuides/V8_V12.md).

#### Renamed Classes

All classes of the Azure Cloud Source have been changed to include the word `Azure`
as a prefix. As a result, the following classes had their name changed:

| 5.9              | 5.10                  |
| ---------------- | --------------------- |
| `CloudBlobPath`  | `AzureBlobPath`       |
| `BlockBlobPath`  | `AzureBlockBlobPath`  |
| `AppendBlobPath` | `AzureAppendBlobPath` |
| `PageBlobPath`   | `AzurePageBlobPath`   |

#### Changed Classes

* The handling of [client-side encryption](https://docs.microsoft.com/en-us/azure/security/fundamentals/encryption-overview#client-side-encryption-of-azure-blobs)
  has undergone some major changes to better match
  the new architecture of the Azure Blob Storage SDK. Changes about this are
  detailed in the below [section](#client-side-encryption).

* `IAzureCloudDirectory`:
  * Now extends `ICloudDirectory<BlobClientBase>` instead of `ICloudDirectory<CloudBlob>`.
  * `getTBlob(String)` return types were updated with the new types from the Azure SDK.

* Removed `IAzureEntityPath.upload(InputStream, long, BlobRequestOptions)`.

  Prefer using `getUnderlying()` to get a reference to the underlying blob client
  and use blob-specific configuration for uploads.

* Uploading with an unknown length is not supported anymore for page blobs, and will throw
  an `UnsupportedOperationException` if attempted.

* `Records#getGlobalDefaultValue` directly uses the content type value passed as an `int` instead of `ILiteralType`.

#### Client-side Encryption

In the Azure Blob Storage SDK, [client-side encryption](https://docs.microsoft.com/en-us/azure/security/fundamentals/encryption-overview#client-side-encryption-of-azure-blobs)
is now implemented in the package
[com.azure:azure-storage-blob-cryptography](https://github.com/Azure/azure-sdk-for-java/tree/master/sdk/storage/azure-storage-blob-cryptography).

With the SDK upgrade, client-side encryption cannot be configured at the Azure
service client level anymore. It needs to be specified on a per-blob basis, before
uploading or downloading content.

As a result, two new classes have been introduced to handle client-side encryption:

* `AzureEncryptedCloudDirectory`: a variant of `AzureCloudDirectory` that
  additionally holds encryption keys for client-side encryption, and that can
  produce `AzureEncryptedBlobPath`s to existing and non-existing encrypted blobs.
* `AzureEncryptedBlobPath`: a path to an encrypted blob; essentially a wrapper around
  an [`EncryptedBlobClient`](https://github.com/Azure/azure-sdk-for-java/tree/master/sdk/storage/azure-storage-blob-cryptography#create-an-encryptedblobclient-from-a-blobclient).

> The other classes `AzureBlobPath`, `AzureBlockBlobPath`, `AzureAppendBlobPath`,
> `AzurePageBlobPath` and `AzureCloudDirectory` are all **unaware** of client-side
> encryption. They will not encrypt uploaded data and will not decrypt downloaded
> data.

They accept three additional arguments in their constructor compared to their
non-encrypted counterparts:

* a key-wrapping algorithm (`String`)
* a key encryption key (`com.azure.core.cryptography.AsyncKeyEncryptionKey`)
* a key encryption key resolver (`com.azure.core.cryptography.AsyncKeyEncryptionKeyResolver`)

If the directory or path only needs to perform either only downloads or only uploads,
some arguments are not required and can be set to `null`:

| operations          | required                                   |
| ------------------- | ------------------------------------------ |
| download            | key encryption key resolver                |
| upload              | key-wrapping algorithm, key encryption key |
| download and upload | all arguments                              |

The possible key wrapping algorithms are specified in the class
[`KeyWrapAlgorithm`](https://github.com/Azure/azure-sdk-for-java/blob/master/sdk/keyvault/azure-security-keyvault-keys/src/main/java/com/azure/security/keyvault/keys/cryptography/models/KeyWrapAlgorithm.java)
from [`com.azure:azure-security-keyvault-keys`](https://github.com/Azure/azure-sdk-for-java/tree/master/sdk/keyvault/azure-security-keyvault-keys)
(the dependency is not included in the Azure Cloud Source).

Some snippets of `AsyncKeyEncryptionKey` creation from a local key or from an
Azure Key Vault can be found in the
[readme of com.azure:azure-storage-blob-cryptography](https://github.com/Azure/azure-sdk-for-java/tree/master/sdk/storage/azure-storage-blob-cryptography#use-a-localkeyencryptionkey).

> **Important**: the new implementation of client-side encryption in Azure Blob
> Storage SDK v12 only permits uploads to client-side-encrypted **block** blobs.
> The creation of client-side-encrypted blobs of other types (append and page)
> is not supported anymore.
>
> Downloads of client-side encrypted page and append blobs that were already created
> through other means is still possible through the `AzureEncryptedBlobPath`.