search

Azure / azure-functions-dotnet-worker

Azure Functions out-of-process .NET language worker
MIT License
410 stars 173 forks source link

POCO ITableEntity int stored as Int64 and cannot be read back to same poco #2402

Open svrooij opened 4 months ago

svrooij commented 4 months ago

Description

It seems that there is some issue with saving a poco in tablestorage. An int gets stored as an Int64 and cannot be read back because (off course) an Int64 cannot be converted to an int.

https://github.com/Azure/azure-sdk-for-net/issues/43443

Steps to reproduce

Here is a reproduction code which you can try yourself. https://github.com/svrooij/long-overdue-int-erubtion

  1. Clone this repository
  2. Open the solution in Visual Studio
  3. Start the Azure Functions
  4. Call the GET /api/CreateItem endpoint
  5. Try to get the item with GET /api/GetItemById/{id} (will not work)
  6. Call the GET /api/CreateItemWithClient endpoint
  7. Try to get the item with GET /api/GetItemById/{id} (will work)
kshyju commented 4 months ago

@svrooij I am investigating this and will share an update on this shortly.

kshyju commented 4 months ago

The code path which handles output binding data uses Newtonsoft.Json.Linq.JObject type to hold the data while passing it through different layers before building a TableEntity class instance which will be used to write it to the Azure table resource.

https://github.com/Azure/azure-sdk-for-net/blob/f0b21e324bb11057411526ab7128ec3d330fdc13/sdk/tables/Microsoft.Azure.WebJobs.Extensions.Tables/src/TablesExtensionConfigProvider.cs#L208-L240

The code tries to read the JObject property value as JValue which stores the numeric value as long(int64)

https://github.com/Azure/azure-sdk-for-net/blob/f0b21e324bb11057411526ab7128ec3d330fdc13/sdk/tables/Microsoft.Azure.WebJobs.Extensions.Tables/src/TablesExtensionConfigProvider.cs#L229-L232

So yes, this is a current limitation. In cases like more fine grained control, we recommend you using the TableClient directly to create the table entity.

svrooij commented 4 months ago

@kshyju how can you complete a still existing issue? Either update the docs to document this issue or fix the actual issue.

Closing this issue with "So yes, this is a current limitation" is a very bad experience!

The code path which handles output binding data uses Newtonsoft.Json.Linq.JObject type

And this statement, makes me wonder when Microsoft will truly migrate to System.Text.Json

kshyju commented 4 months ago

@svrooij Sorry! I agree this should not be closed. I am re-opening it to track the work needed to make possible improvements in this case.