EntityProperty (and DynamicTableEntity) handling of nulls doesn't match REST API

[davidmatson]

EntityProperty distinguishes between null values of different types. I was about to write code to support creating a property with a null GUID vs a null string vs a null Int32, etc. However, from a REST API standpoint, there is no such distinction - any null is a null, and a data type for the null is irrelevant when passed to the storage REST API. Having EntityProperty have a BooleanValue of type bool?, vs a GuidValue of type Guid? with a different PropertyType on these two instances doesn't fit the domain.

Note also that null values are never stored by Azure Table Storage, so there's no need to be able to read an EntityProperty with a null value and then worry about distinguishing a null bool? vs a null Guid? etc when reading - the service would never return a null value to begin with.

I understand that having TableEntity support properties with types like int? and Guid? is useful - I'm not suggesting any changes there. It's at the EntityProperty/DynamicTableEntity level that I think there's a problem (distinguishing null int? vs null bool? there doesn't fit the service's data model).

(Copied from Azure/azure-storage-net#548.)

[davidmatson]

FWIW, #33 has a broader suggestion to consider; if that suggestion were adopted, this issue would moot. If not, this is worth considering separately.

[davidmatson]

I think the hardest part here is having all the accessor properties be nullable when reading an entity. Having to do things like:

property.BooleanValue.Value

everywhere instead of just

property.BooleanValue

isn't ideal.

I think null would be better handled (if at all, as discussed in the other issue) via a bool property.IsNull, which fits the Table Data Model better, rather than having separate nullable versions of every type.