Package renamed to NServiceBus.Persistence.AzureTable
This package was formerly known as NServiceBus.
. As of version 3 the package name is NServiceBus.
.
Types from namespace NServiceBus.Persistence.AzureStorage
moved to NServiceBus.Persistence.AzureTable
Certain advanced configuration APIs have been moved from the namespace NServiceBus.
to using NServiceBus.
. The code must be adjusted accordingly. A straight forward way is to perform a search and replace:
using NServiceBus.Persistence.AzureStorage;
to
using NServiceBus.Persistence.AzureTable;
Move to .NET 4.7.2
The minimum .NET Framework version is .NET Framework 4.7.2.
All projects must be updated to .NET Framework 4.7.2 before upgrading to NServiceBus.Persistence.AzureTable version 3.
It is recommended to update to .NET Framework 4.7.2 and perform a full migration to production before updating to version 3. This will isolate any issues that may occur.
For solutions with many projects, the Target Framework Migrator Visual Studio extension can reduce the manual effort required in performing an upgrade.
Compatibility
The package is fully compatible with the NServiceBus.Persistence.AzureStorage version 1 and 2. It supports both sagas that use secondary index entries as well as sagas that don't have a secondary index entries. By default the persister operates in the compatibility mode but doesn't fall back to full table scans. If compatibility with sagas stored with Version 1 of the persister is required full table scan has to be enabled.
For newly introduced endpoints it is encouraged to disable the compatibility mode due to performance reasons/
Support for Azure Table Storage and Azure Cosmos DB Table API
The Azure Table Persistence supports both Table Storage and Azure Cosmos DB Table API.
Migrating from Azure Tables to Azure Cosmos Tables
For more information on how to migrate from Azure storage tables to Cosmos tables, follow the migration guide.
Transactionality
The Azure Table Persistence has been enhanced to leverage transactional API to atomically store data when using sagas or outbox. Multiple operations are atomically stored by making use of the TableBatchOperation API, only when the data is stored in the same partition within a container
Note that this is not the default. To enable transactionality, a custom behavior needs to be put in place to identify the partition key. The documentation explains the details on how to do this, including a sample as well.
Installers
To make sure the persistence complies with the principle of least privilege, the previous CreateSchema
-method has been deprecated in favour of integration with the Installers-API available on the endpoint configuration.
To enable the persistence to create the needed table(s), the endpoint will need to EnableInstallers()
, which will result in the tables being created at endpoint startup when a default table was set, or at runtime when the table information is made available.
To opt out of creating tables while still making use of the capabilities provided by EnableInstallers()
, the DisableTableCreation
method can be invoked.
Timeout storage
Timeout storage support was marked obsolete with a warning in version 2 because both Azure transports natively support delayed delivery. In version 3, timeout storage has been removed entirely.
- Any timeout-related configuration APIs can be safely removed.
- Database tables must be manually removed from storage.
There is no automatic migration of timeout data. See Migrating from timeout manager to native delivery.