Daniel Chambers

@isaacabraham It's probably worthwhile investigating what exactly table storage returns when properties are too big, and if we can leverage that for better errors, great, that'll save us the effort...

I think we should be able to support serialized properties as values in queries too. ``` fsharp Query.all |> Query.where (fun t s -> t.SerializedProperty = (1, "test")) |> fromSomeTable...

A use case for the above is if you want a custom serializer that transforms, for example, a long into a zero-padded string representation of `long.MaxValue - myLong` (for reverse...

That's a good point. My thoughts on this is that serializer authors can ensure that themselves. Perhaps we could make them put an attribute or a property on the serializer...

I see your point that it's dangerous to assume that the serializer generates stable values for comparison purposes. But I'm loathe to say that as soon as a serializer is...

Are you saying you'd reckon it'd be better to just not support serialized properties in queries, and if someone wants that then they need to do it themselves manually rather...

Hmm, well I guess we can leave it out in the first version, and if we find that people have good use cases for adding it later, we can add...

Pretty sure when I started this library, you couldn't make records value types. I'm not fundamentally opposed to the idea, but it would be a gentle breaking change. Did you...

This is very doable. However, if something like #14 was implemented would that make the need for this redundant (ie you could configure a custom serializer to ticksify your timespans...

That's true, though I'd argue the ordering thing is kinda moot since ordering only really matters on the PartitionKey and RowKey properties, which must be strings, so you'd need to...