Supported data types (Azure Search)
Document fields and values in expressions (for example, in filters) are typed according to the Entity Data Model, or EDM (see Entity Data Model (MSDN) for details). Azure Search uses the following data types.
If you're using indexers to pull data into Azure Search, indexers have different data type mappings for JSON and SQL Server data sources. See Data type map for indexers in Azure Search for details.
EDM data types used in Azure Search indexes and documents
|Edm.String||Text that can optionally be tokenized for full-text search (word-breaking, stemming, etc.)|
|Collection(Edm.String)||A list of strings that can optionally be tokenized for full-text search. There is no theoretical upper limit on the number of items in a collection, but the 16 MB upper limit on payload size applies to collections.|
|Edm.Boolean||Contains true/false values.|
|Edm.Int32||32-bit integer values.|
|Edm.Int64||64-bit integer values.|
|Edm.Double||Double-precision numeric data|
|Edm.DateTimeOffset||Date time values represented in the OData V4 format:
|Edm.GeographyPoint||A point representing a geographic location on the globe. For request and response bodies the representation of values of this type follows the GeoJSON "Point" type format. For URLs OData uses a literal form based on the WKT standard. A point literal is constructed as geography'POINT(lon lat)'.|
All of the above types are nullable, except for Collection(Edm.String). Nullable fields can be explicitly set to null. They are automatically set to null when omitted from a document that is uploaded t an Azure Search index. Collection(Edm.String) fields are automatically set to empty ('' in JSON) when they are omitted from a document.
Other EDM structures used in Azure Search
Edm.GeographyPolygon is a polygon representing a geographic region on the globe. While this type cannot be used in document fields, it can be used as an argument to the
geo.intersects function. The literal form for URLs in OData is based on the WKT (Well-known text) and OGC's simple feature access standards. A polygon literal is constructed as geography'POLYGON((lon lat, lon lat, ...))'.
To learn more about geospatial search in Azure, see this video: Azure Search and Geospatial Data
Points in a polygon must be in counterclockwise order. Points in a polygon are interpreted in counterclockwise order, relative to the inside of the polygon. For example, a 4-point closed polygon around London would be -0.3°W 51.6°N [top left] , -0.3°W 51.4°N [bottom left], 0.1°E 51.4°N [bottom right], 0.1°E 51.6°N [top right], -0.3°W 51.6°N [starting point].
Azure Search Service REST
HTTP status codes (Azure Search)
Support for OData (Azure Search)
Create Index (Azure Search Service REST API)
Add, Update or Delete Documents (Azure Search Service REST API)
Indexer operations (Azure Search Service REST API)
Azure Search .NET SDK