Use OData type annotations to disambiguate property types when persisting #235
Labels
enhancement
New feature or request
Comments
kzu
added a commit
that referenced
this issue
Jul 25, 2023
Previously, we didn't ever annotate properties with OData Edm types, meaning the following supported native column types in Azure Tables would all be converted (and used) as plain strings: byte[], DateTimeOffset, Guid and long. By following more closely the documentation at https://learn.microsoft.com/en-us/rest/api/storageservices/payload-format-for-table-service-operations#property-types-in-a-json-feed, we effectively make our API more optimal and compatible with the Azure SDK for Table Storage. In order to avoid too many breaking changes, we only support Edm.DateTime annotation for DateTimeOffset properties, since that's the behavior of the SDK when deserializing such annotated values (not to DateTime). This effectively means that DateTime is more of a legacy type that might best be avoided. This also now allows using a GUID-typed property for both partition and row keys. Closes #235.
kzu
added a commit
that referenced
this issue
Jul 25, 2023
Previously, we didn't ever annotate properties with OData Edm types, meaning the following supported native column types in Azure Tables would all be converted (and used) as plain strings: byte[], DateTimeOffset, Guid and long. By following more closely the documentation at https://learn.microsoft.com/en-us/rest/api/storageservices/payload-format-for-table-service-operations#property-types-in-a-json-feed, we effectively make our API more optimal and compatible with the Azure SDK for Table Storage. In order to avoid too many breaking changes, we only support Edm.DateTime annotation for DateTimeOffset properties, since that's the behavior of the SDK when deserializing such annotated values (not to DateTime). This effectively means that DateTime is more of a legacy type that might best be avoided. This also now allows using a GUID-typed property for both partition and row keys. Closes #235.
kzu
added a commit
that referenced
this issue
Jul 25, 2023
Previously, we didn't ever annotate properties with OData Edm types, meaning the following supported native column types in Azure Tables would all be converted (and used) as plain strings: byte[], DateTimeOffset, Guid and long. By following more closely the documentation at https://learn.microsoft.com/en-us/rest/api/storageservices/payload-format-for-table-service-operations#property-types-in-a-json-feed, we effectively make our API more optimal and compatible with the Azure SDK for Table Storage. In order to avoid too many breaking changes, we only support Edm.DateTime annotation for DateTimeOffset properties, since that's the behavior of the SDK when deserializing such annotated values (not to DateTime). This effectively means that DateTime is more of a legacy type that might best be avoided. This also now allows using a GUID-typed property for both partition and row keys. Closes #235.
kzu
added a commit
that referenced
this issue
Jul 25, 2023
Previously, we didn't ever annotate properties with OData Edm types, meaning the following supported native column types in Azure Tables would all be converted (and used) as plain strings: byte[], DateTimeOffset, Guid and long. By following more closely the documentation at https://learn.microsoft.com/en-us/rest/api/storageservices/payload-format-for-table-service-operations#property-types-in-a-json-feed, we effectively make our API more optimal and compatible with the Azure SDK for Table Storage. In order to avoid too many breaking changes, we only support Edm.DateTime annotation for DateTimeOffset properties, since that's the behavior of the SDK when deserializing such annotated values (not to DateTime). This effectively means that DateTime is more of a legacy type that might best be avoided. This also now allows using a GUID-typed property for both partition and row keys. Closes #235.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
According to the documentation on updating via JSON payloads, automatic inference of column types might not be possible in all cases. It may be necessary to add OData type annotations for those properties to properly persist in the proper native Table service column type.
The text was updated successfully, but these errors were encountered: