Azure Functions integrates with Azure Tables via triggers and bindings. Integrating with Azure Tables allows you to build functions that read and write data using Azure Cosmos DB for Table and Azure Table Storage.
Install extensionThe extension NuGet package you install depends on the C# mode you're using in your function app:
The process for installing the extension varies depending on the extension version:
This section describes using a class library. For C# scripting, you would need to instead install the extension bundle, version 4.x.
This version introduces the ability to connect using an identity instead of a secret. For a tutorial on configuring your function apps with managed identities, see the creating a function app with identity-based connections tutorial.
This version allows you to bind to types from Azure.Data.Tables. It also introduces the ability to use Azure Cosmos DB for Table.
This extension is available by installing the Microsoft.Azure.WebJobs.Extensions.Tables NuGet package into a project using version 5.x or higher of the extensions for blobs and queues.
Using the .NET CLI:
# Install the Azure Tables extension
dotnet add package Microsoft.Azure.WebJobs.Extensions.Tables
# Update the combined Azure Storage extension (to a version which no longer includes Azure Tables)
dotnet add package Microsoft.Azure.WebJobs.Extensions.Storage
Note
Azure Blobs, Azure Queues, and Azure Tables now use separate extensions and are referenced individually. For example, to use the triggers and bindings for all three services in your .NET in-process app, you should add the following packages to your project:
Previously, the extensions shipped together as Microsoft.Azure.WebJobs.Extensions.Storage, version 4.x. This same package also has a 5.x version, which references the split packages for blobs and queues only. When upgrading your package references from older versions, you may therefore need to additionally reference the new Microsoft.Azure.WebJobs.Extensions.Tables NuGet package. Also, when referencing these newer split packages, make sure you are not referencing an older version of the combined storage package, as this will result in conflicts from two definitions of the same bindings.
This section describes using a class library. For C# scripting, you would need to instead install the extension bundle, version 2.x.
Working with the bindings requires that you reference the appropriate NuGet package. Tables are included in a combined package for Azure Storage. Install the Microsoft.Azure.WebJobs.Extensions.Storage NuGet package, version 3.x or 4.x.
Note
Tables have been moved out of this package starting in its 5.x version. You need to instead use version 4.x of the extension NuGet package or additionally include the Azure Tables extension when using version 5.x.
Functions 1.x apps automatically have a reference the Microsoft.Azure.WebJobs NuGet package, version 2.x.
In Functions 1.x, the Storage triggers and bindings use version 7.2.1 of the Azure Storage SDK (WindowsAzure.Storage NuGet package). If you reference a different version of the Storage SDK, and you bind to a Storage SDK type in your function signature, the Functions runtime may report that it can't bind to that type. The solution is to make sure your project references WindowsAzure.Storage 7.2.1.
This version introduces the ability to connect using an identity instead of a secret. For a tutorial on configuring your function apps with managed identities, see the creating a function app with identity-based connections tutorial.
This version allows you to bind to types from Azure.Data.Tables. It also introduces the ability to use Azure Cosmos DB for Table.
This extension is available by installing the Microsoft.Azure.Functions.Worker.Extensions.Tables NuGet package into a project using version 5.x or higher of the extensions for blobs and queues.
Using the .NET CLI:
# Install the Azure Tables extension
dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Tables --version 1.0.0
# Update the combined Azure Storage extension (to a version which no longer includes Azure Tables)
dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Storage --version 5.0.0
Note
Azure Blobs, Azure Queues, and Azure Tables now use separate extensions and are referenced individually. For example, to use the triggers and bindings for all three services in your .NET isolated-process app, you should add the following packages to your project:
Previously, the extensions shipped together as Microsoft.Azure.Functions.Worker.Extensions.Storage, version 4.x. This same package also has a 5.x version, which references the split packages for blobs and queues only. When upgrading your package references from older versions, you may therefore need to additionally reference the new Microsoft.Azure.Functions.Worker.Extensions.Tables NuGet package. Also, when referencing these newer split packages, make sure you are not referencing an older version of the combined storage package, as this will result in conflicts from two definitions of the same bindings.
If you're writing your application using F#, you must also configure this extension as part of the app's startup configuration. In the call to ConfigureFunctionsWorkerDefaults() or ConfigureFunctionsWebApplication(), add a delegate that takes an IFunctionsWorkerApplication parameter. Then within the body of that delegate, call ConfigureTablesExtension() on the object:
let hostBuilder = new HostBuilder()
hostBuilder.ConfigureFunctionsWorkerDefaults(fun (context: HostBuilderContext) (appBuilder: IFunctionsWorkerApplicationBuilder) ->
appBuilder.ConfigureTablesExtension() |> ignore
) |> ignore
Tables are included in a combined package for Azure Storage. Install the Microsoft.Azure.Functions.Worker.Extensions.Storage NuGet package, version 4.x.
Note
Tables have been moved out of this package starting in its 5.x version. You need to instead use version 4.x of the extension NuGet package or additionally include the Azure Tables extension when using version 5.x.
Functions version 1.x doesn't support isolated worker process.
Install bundleThe Azure Tables bindings are part of an extension bundle, which is specified in your host.json project file. You may need to modify this bundle to change the version of the bindings, or if bundles aren't already installed. To learn more, see extension bundle.
Binding typesThe binding types supported for .NET depend on both the extension version and C# execution mode, which can be one of the following:
An isolated worker process class library compiled C# function runs in a process isolated from the runtime.
An in-process class library is a compiled C# function runs in the same process as the Functions runtime.
Choose a version to see binding type details for the mode and version.
The Azure Tables extension supports parameter types according to the table below.
Binding scenario Parameter types Table input (single entity) A type deriving from ITableEntity Table input (multiple entities from query)IEnumerable<T> where T derives from ITableEntity
ICollector<T> or IAsyncCollector<T> where T implements ITableEntity
Earlier versions of the extension exposed types from the now deprecated Microsoft.Azure.Cosmos.Table namespace. Newer types from Azure.Data.Tables are exclusive to the Azure Tables extension.
This version of the extension supports parameter types according to the table below.
Binding scenario Parameter types Table input A plain old CLR object (POCO) representing the entityFunctions 1.x exposed types from the deprecated Microsoft.WindowsAzure.Storage.Table namespace. Newer types from Azure.Data.Tables are exclusive to the Azure Tables extension. To use these, you will need to upgrade your application to Functions 4.x.
The isolated worker process supports parameter types according to the tables below. Support for binding to types from Azure.Data.Tables is in preview.
Azure Tables input binding
When working with a single table entity, the Azure Tables input binding can bind to the following types:
Type Description A JSON serializable type that implements ITableEntity Functions attempts to deserialize the entity into a plain-old CLR object (POCO) type. The type must implement ITableEntity or have a stringRowKey property and a string PartitionKey property. TableEntity1 The entity as a dictionary-like type.
When working with multiple entities from a query, the Azure Tables input binding can bind to the following types:
Type DescriptionIEnumerable<T> where T implements ITableEntity An enumeration of entities returned by the query. Each entry represents one entity. The type T must implement ITableEntity or have a string RowKey property and a string PartitionKey property. TableClient1 A client connected to the table. This offers the most control for processing the table and can be used to write to it if the connection has sufficient permission.
1 To use these types, you need to reference Microsoft.Azure.Functions.Worker.Extensions.Tables 1.2.0 or later and the common dependencies for SDK type bindings.
Azure Tables output binding
When you want the function to write to a single entity, the Azure Tables output binding can bind to the following types:
Type Description A JSON serializable type that implements [ITableEntity] Functions attempts to serialize a plain-old CLR object (POCO) type as the entity. The type must implement [ITableEntity] or have a stringRowKey property and a string PartitionKey property.
When you want the function to write to multiple entities, the Azure Tables output binding can bind to the following types:
Type DescriptionT[] where T is one of the single entity types An array containing multiple entities. Each entry represents one entity.
For other output scenarios, create and use a TableClient with other types from Azure.Data.Tables directly. See Register Azure clients for an example of using dependency injection to create a client type from the Azure SDK.
Earlier versions of extensions in the isolated worker process only support binding to plain-old CLR object (POCO) types. Additional options are available to the Azure Tables extension.
Functions version 1.x doesn't support isolated worker process. To use the isolated worker model, upgrade your application to Functions 4.x.
Next stepsRetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4