Dictionary datatype is very common. Often, we'd like to store our data as a dictionary. Currently, I serialize and store it as a string. It'd be great if the dictionary type is supported.267 votes
Search should ingest and support a true implementation of DateTimeOffset. The current implementation merely converts an incoming DateTimeOffset to a DateTime in UTC, subsequently resulting in the loss of data, as the original offset can no longer be retrieved. The currently implementation necessitates persisting a related sidecar attribute of the original offset and subsequently requires the consumer to convert and rehydrate the property. This is exceptionally tedious, especially for use cases with several dozen DateTimeOffset attributes with varying offsets.26 votes
We really like this idea. Thank you for your feedback. We’re considering this for a future release of Azure Search.
Azure Cognitive Search Product Team
Azure Search only supports Edm.DateTimeOffset. This is great for timestamps and other point-in-time data. However, it's horrible for things like birthdays, invoice dates, and other whole-date scenarios.
1976-08-27 is very different than 1976-08-27T00:00:00Z.
Edm.Date was added to OData v4 for this exact reason. It should be a primitive type in Azure Search as well.16 votes
Thank you for your feedback. We’re considering this for a future release of Azure Search.
Azure Search Product Team
- Don't see your idea?