- .NET Clients: other versions:
- Introduction
- Breaking changes
- API Conventions
- Elasticsearch.Net - Low level client
- NEST - High level client
- Troubleshooting
- Search
- Query DSL
- Full text queries
- Term level queries
- Exists Query Usage
- Fuzzy Date Query Usage
- Fuzzy Numeric Query Usage
- Fuzzy Query Usage
- Ids Query Usage
- Prefix Query Usage
- Date Range Query Usage
- Numeric Range Query Usage
- Term Range Query Usage
- Regexp Query Usage
- Term Query Usage
- Terms List Query Usage
- Terms Lookup Query Usage
- Terms Query Usage
- Type Query Usage
- Wildcard Query Usage
- Compound queries
- Joining queries
- Geo queries
- Geo Bounding Box Query Usage
- Geo Distance Query Usage
- Geo Distance Range Query Usage
- Geo Hash Cell Query Usage
- Geo Polygon Query Usage
- Geo Shape Circle Query Usage
- Geo Shape Envelope Query Usage
- Geo Shape Geometry Collection Query Usage
- Geo Shape Indexed Shape Query Usage
- Geo Shape Line String Query Usage
- Geo Shape Multi Line String Query Usage
- Geo Shape Multi Point Query Usage
- Geo Shape Multi Polygon Query Usage
- Geo Shape Point Query Usage
- Geo Shape Polygon Query Usage
- Specialized queries
- Span queries
- NEST specific queries
- Aggregations
- Metric Aggregations
- Average Aggregation Usage
- Cardinality Aggregation Usage
- Extended Stats Aggregation Usage
- Geo Bounds Aggregation Usage
- Geo Centroid Aggregation Usage
- Max Aggregation Usage
- Min Aggregation Usage
- Percentile Ranks Aggregation Usage
- Percentiles Aggregation Usage
- Scripted Metric Aggregation Usage
- Stats Aggregation Usage
- Sum Aggregation Usage
- Top Hits Aggregation Usage
- Value Count Aggregation Usage
- Bucket Aggregations
- Adjacency Matrix Usage
- Children Aggregation Usage
- Date Histogram Aggregation Usage
- Date Range Aggregation Usage
- Filter Aggregation Usage
- Filters Aggregation Usage
- Geo Distance Aggregation Usage
- Geo Hash Grid Aggregation Usage
- Global Aggregation Usage
- Histogram Aggregation Usage
- Ip Range Aggregation Usage
- Missing Aggregation Usage
- Nested Aggregation Usage
- Range Aggregation Usage
- Reverse Nested Aggregation Usage
- Sampler Aggregation Usage
- Significant Terms Aggregation Usage
- Terms Aggregation Usage
- Pipeline Aggregations
- Average Bucket Aggregation Usage
- Bucket Script Aggregation Usage
- Bucket Selector Aggregation Usage
- Cumulative Sum Aggregation Usage
- Derivative Aggregation Usage
- Extended Stats Bucket Aggregation Usage
- Max Bucket Aggregation Usage
- Min Bucket Aggregation Usage
- Moving Average Ewma Aggregation Usage
- Moving Average Holt Linear Aggregation Usage
- Moving Average Holt Winters Aggregation Usage
- Moving Average Linear Aggregation Usage
- Moving Average Simple Aggregation Usage
- Percentiles Bucket Aggregation Usage
- Serial Differencing Aggregation Usage
- Stats Bucket Aggregation Usage
- Sum Bucket Aggregation Usage
- Matrix Aggregations
- Metric Aggregations
WARNING: Version 5.x has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
Auto mapping
editAuto mapping
editWhen creating a mapping either when creating an index or through the Put Mapping API, NEST offers a feature called auto mapping that can automagically infer the correct Elasticsearch field datatypes from the CLR POCO property types you are mapping.
We’ll look at the features of auto mapping with a number of examples. For this,
we’ll define two POCOs, Company
, which has a name
and a collection of Employees, and Employee
which has various properties of
different types, and itself has a collection of Employee
types.
public class Company { public string Name { get; set; } public List<Employee> Employees { get; set; } } public class Employee { public string FirstName { get; set; } public string LastName { get; set; } public int Salary { get; set; } public DateTime Birthday { get; set; } public bool IsManager { get; set; } public List<Employee> Employees { get; set; } public TimeSpan Hours { get; set; } }
Auto mapping can take the pain out of having to define a manual mapping for all properties on the POCO
var createIndexResponse = _client.CreateIndex("myindex", c => c .Mappings(ms => ms .Map<Company>(m => m.AutoMap()) .Map<Employee>(m => m.AutoMap()) ) );
This produces the following JSON request
{ "mappings": { "company": { "properties": { "employees": { "properties": { "birthday": { "type": "date" }, "employees": { "properties": {}, "type": "object" }, "firstName": { "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } }, "type": "text" }, "hours": { "type": "long" }, "isManager": { "type": "boolean" }, "lastName": { "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } }, "type": "text" }, "salary": { "type": "integer" } }, "type": "object" }, "name": { "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } }, "type": "text" } } }, "employee": { "properties": { "birthday": { "type": "date" }, "employees": { "properties": {}, "type": "object" }, "firstName": { "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } }, "type": "text" }, "hours": { "type": "long" }, "isManager": { "type": "boolean" }, "lastName": { "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } }, "type": "text" }, "salary": { "type": "integer" } } } } }
var connectionSettings = new ConnectionSettings(new InMemoryConnection()) .DisableDirectStreaming() .InferMappingFor<ParentWithStringId>(m => m .TypeName("parent") .Ignore(p => p.Description) .Ignore(p => p.IgnoreMe) ); var client = new ElasticClient(connectionSettings); var createIndexResponse = client.CreateIndex("myindex", c => c .Mappings(ms => ms .Map<ParentWithStringId>(m => m .AutoMap() ) ) );
we’re using an in memory connection for this example. In your production application though, you’ll want to use an |
|
we disable direct streaming here to capture the request and response bytes. In your production application however, you’ll likely not want to do this, since it causes the request and response bytes to be buffered in memory. |
{ "mappings": { "parent": { "properties": { "id": { "type": "text", "fields": { "keyword": { "ignore_above": 256, "type": "keyword" } } } } } } }
Observe that NEST has inferred the Elasticsearch types based on the CLR type of our POCO properties. In this example,
-
Birthday is mapped as a
date
, -
Hours is mapped as a
long
(TimeSpan
ticks) -
IsManager is mapped as a
boolean
, -
Salary is mapped as an
integer
-
Employees is mapped as an
object
and the remaining string properties as multi field text
datatypes, each with a keyword
datatype
sub field.
NEST has inferred mapping support for the following .NET types
|
maps to |
|
maps to |
|
maps to |
|
maps to |
|
maps to |
|
maps to |
|
maps to |
|
maps to |
|
maps to |
|
maps to |
|
maps to |
|
maps to |
|
maps to |
|
maps to |
|
maps to |
|
maps to |
|
maps to |
and supports a number of special types defined in NEST
|
maps to |
|
maps to |
|
maps to |
|
maps to |
|
maps to |
|
maps to |
|
maps to |
All other types map to "object"
by default.
Some .NET types do not have direct equivalent Elasticsearch types. For example, System.Decimal
is a type
commonly used to express currencies and other financial calculations that require large numbers of significant
integral and fractional digits and no round-off errors. There is no equivalent type in Elasticsearch, and the
nearest type is double, a double-precision 64-bit IEEE 754 floating point.
When a POCO has a System.Decimal
property, it is automapped to the Elasticsearch double
type. With the caveat
of a potential loss of precision, this is generally acceptable for a lot of use cases, but it can however cause
problems in some edge cases.
As the C# Specification states,
For a conversion from decimal to float or double , the decimal value is rounded to the nearest double or float value.
While this conversion may lose precision, it never causes an exception to be thrown.
|
||
-- C# Specification section 6.2.1 |
This conversion causes an exception to be thrown at deserialization time for Decimal.MinValue
and Decimal.MaxValue
because, at
serialization time, the nearest double
value that is converted to is outside of the bounds of Decimal.MinValue
or Decimal.MaxValue
,
respectively. In these cases, it is advisable to use double
as the POCO property type.
Mapping Recursion
editIf you notice in our previous Company
and Employee
example, the Employee
type is recursive
in that the Employee
class itself contains a collection of type Employee
. By default, .AutoMap()
will only
traverse a single depth when it encounters recursive instances like this; the collection of type Employee
on the Employee
class did not get any of its properties mapped.
This is done as a safe-guard to prevent stack overflows and all the fun that comes with
infinite recursion. Additionally, in most cases, when it comes to Elasticsearch mappings, it is
often an edge case to have deeply nested mappings like this. However, you may still have
the need to do this, so you can control the recursion depth of .AutoMap()
.
Let’s introduce a very simple class, A
, which itself has a property
Child of type A
.
public class A { public A Child { get; set; } }
By default, .AutoMap()
only goes as far as depth 1
var createIndexResponse = _client.CreateIndex("myindex", c => c .Mappings(ms => ms .Map<A>(m => m.AutoMap()) ) );
Thus we do not map properties on the second occurrence of our Child property
{ "mappings": { "a": { "properties": { "child": { "properties": {}, "type": "object" } } } } }
Now let’s specify a maxRecursion of 3
createIndexResponse = _client.CreateIndex("myindex", c => c .Mappings(ms => ms .Map<A>(m => m.AutoMap(3)) ) );
.AutoMap()
has now mapped three levels of our Child property
{ "mappings": { "a": { "properties": { "child": { "type": "object", "properties": { "child": { "type": "object", "properties": { "child": { "type": "object", "properties": { "child": { "type": "object", "properties": {} } } } } } } } } } } }
On this page