Skip to main content

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
  • 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 locationNew location
com.qfs.func.IBiIntPredicatecom.activeviam.util.function.BiIntPredicate
com.qfs.func.IFloatUnaryOperatorcom.activeviam.util.function.FloatUnaryOperator
com.qfs.func.IntBiFunctioncom.activeviam.util.function.IntBiFunction
com.qfs.func.ITriFunctioncom.activeviam.util.function.TriFunction
com.quartetfs.fwk.util.FloatBinaryOperatorcom.activeviam.util.function.FloatBinaryOperator
com.qfs.func.IEithercom.activeviam.util.function.IEither
com.qfs.func.IOptionalEithercom.activeviam.util.function.IOptionalEither
com.qfs.func.impl.Eithercom.activeviam.util.function.impl.Either
com.qfs.func.impl.OptionalEithercom.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.

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.

A migration guide from v8 to v12 can be found on the Azure SDK repository.

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.95.10
CloudBlobPathAzureBlobPath
BlockBlobPathAzureBlockBlobPath
AppendBlobPathAzureAppendBlobPath
PageBlobPathAzurePageBlobPath

Changed Classes​

  • The handling of client-side encryption 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.

  • 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 is now implemented in the package com.azure: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 AzureEncryptedBlobPaths to existing and non-existing encrypted blobs.
  • AzureEncryptedBlobPath: a path to an encrypted blob; essentially a wrapper around an EncryptedBlobClient.

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 from com.azure: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.

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.