If a POJO model inherits from TableServiceEntity, @TableInput annotation does not populate the PartitionKey & RowKey.
This is not a good experience for a few reasons:
PartitionKey & RowKey in the table were never defined by the user. Microsoft defined them in the table; so Microsoft needs to find a way to give the developer access to them. What if the names were changed by Microsoft at anytime?
The user might want to use the same POJO model that they use with the TableInput in other parts of the project that could use Table Storage APIs.
The current workaround is to explicitly define getPartitionKey & getRowKey methods with the @StoreAs annotation.
I think the Functions/Functions SDK team can have multiple options for tackling this, each with their own pros & cons:
Toggling GSON's case insensetivity.
Adding a layer on top of GSON to specifically target the exact broken scenario, by explicitly setting the partitionKey & rowKey if the object implements TableEntity.
Working with the storage team to find a better solution?
If a POJO model inherits from TableServiceEntity, @TableInput annotation does not populate the PartitionKey & RowKey.
This is not a good experience for a few reasons:
The current workaround is to explicitly define getPartitionKey & getRowKey methods with the @StoreAs annotation.
I think the Functions/Functions SDK team can have multiple options for tackling this, each with their own pros & cons:
Toggling GSON's case insensetivity.
Adding a layer on top of GSON to specifically target the exact broken scenario, by explicitly setting the partitionKey & rowKey if the object implements TableEntity.
Working with the storage team to find a better solution?