How to set up mapping for common property across all types in index

I have a property that is common to all my document types. I would now like
to apply a custom mapping to this property across an entire index. I can't
use default-mapping.json because that's applied to all indexes and I need
to be able to support different versions of mappings between indexes. Is
there any other way to specify a mapping for a common property, other than
explicitly repeating it for each type in my index creation api call? I have
numerous types and want to avoid that level of verbosity if possible.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Hey

have you seen the index template feature of elasticsearch at

maybe that feature can help you.

--Alex

On Fri, Jul 12, 2013 at 11:38 PM, Paul Bellora bellorap@gmail.com wrote:

I have a property that is common to all my document types. I would now
like to apply a custom mapping to this property across an entire index. I
can't use default-mapping.json because that's applied to all indexes and I
need to be able to support different versions of mappings between indexes.
Is there any other way to specify a mapping for a common property, other
than explicitly repeating it for each type in my index creation api call? I
have numerous types and want to avoid that level of verbosity if possible.

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Hmm, that's interesting but it still appears to define mappings on a
per-type basis, at least in that page's examples. Is there a way I can
leverage index templates to define mappings across all types in the index?

On Mon, Jul 15, 2013 at 2:20 AM, Alexander Reelsen alr@spinscale.de wrote:

Hey

have you seen the index template feature of elasticsearch at
Elasticsearch Platform — Find real-time answers at scale | Elastic
maybe that feature can help you.

--Alex

On Fri, Jul 12, 2013 at 11:38 PM, Paul Bellora bellorap@gmail.com wrote:

I have a property that is common to all my document types. I would now
like to apply a custom mapping to this property across an entire index. I
can't use default-mapping.json because that's applied to all indexes and I
need to be able to support different versions of mappings between indexes.
Is there any other way to specify a mapping for a common property, other
than explicitly repeating it for each type in my index creation api call? I
have numerous types and want to avoid that level of verbosity if possible.

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/nw4LTAmkmPs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Hi,
you can use the default type. Have a look
here: Elasticsearch Platform — Find real-time answers at scale | Elastic
.

The default type is really handy when you have multiple types with a lot
of similarities. You may want to avoid duplications, thus you define the
common fields once under the default type, which will be applied
automatically to all the types that belong to the current index. And of
course you can combine it with index templates too.

Cheers
Luca

On Monday, July 15, 2013 5:43:44 PM UTC+2, Paul Bellora wrote:

Hmm, that's interesting but it still appears to define mappings on a
per-type basis, at least in that page's examples. Is there a way I can
leverage index templates to define mappings across all types in the index?

On Mon, Jul 15, 2013 at 2:20 AM, Alexander Reelsen <a...@spinscale.de<javascript:>

wrote:

Hey

have you seen the index template feature of elasticsearch at
Elasticsearch Platform — Find real-time answers at scale | Elastic
maybe that feature can help you.

--Alex

On Fri, Jul 12, 2013 at 11:38 PM, Paul Bellora <bell...@gmail.com<javascript:>

wrote:

I have a property that is common to all my document types. I would now
like to apply a custom mapping to this property across an entire index. I
can't use default-mapping.json because that's applied to all indexes and I
need to be able to support different versions of mappings between indexes.
Is there any other way to specify a mapping for a common property, other
than explicitly repeating it for each type in my index creation api call? I
have numerous types and want to avoid that level of verbosity if possible.

--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearc...@googlegroups.com <javascript:>.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/nw4LTAmkmPs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearc...@googlegroups.com <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Interesting - the concept is exactly what I'm looking for. Unfortunately it
can't be applied in the way I'd hoped:

curl -X PUT localhost:9200/test -d '{
"mappings" : {
"default" : {
"properties" : {
"foo" : { "index" : "unanalyzed" }
}
}
}
}'

This yields:

MapperParsingException[mapping [default]]; nested:
MapperParsingException[No type specified for property [foo]];

The documentation says:

The default mapping definition can be overridden in several manners. The
simplest manner is to simply define a file called default-mapping.json and
placed it under the config directory (which can be configured to exist in a
different location). It can also be explicitly set using the
index.mapper.default_mapping_location setting.

So it seems like I would need to make a default mappings file for each
index and use the default_mapping_location property to point to it. This is
enough of an inconvenience to my reindexing workflow that I think I'll just
stick to the verbose index settings. Thanks for the suggestions though!

On Tue, Jul 16, 2013 at 7:29 AM, Luca Cavanna cavannaluca@gmail.com wrote:

Hi,
you can use the default type. Have a look here:
Elasticsearch Platform — Find real-time answers at scale | Elastic .

The default type is really handy when you have multiple types with a lot
of similarities. You may want to avoid duplications, thus you define the
common fields once under the default type, which will be applied
automatically to all the types that belong to the current index. And of
course you can combine it with index templates too.

Cheers
Luca

On Monday, July 15, 2013 5:43:44 PM UTC+2, Paul Bellora wrote:

Hmm, that's interesting but it still appears to define mappings on a
per-type basis, at least in that page's examples. Is there a way I can
leverage index templates to define mappings across all types in the index?

On Mon, Jul 15, 2013 at 2:20 AM, Alexander Reelsen a...@spinscale.dewrote:

Hey

have you seen the index template feature of elasticsearch at
http://www.elasticsearch.org/guide/reference/api/admin-
indices-templates/http://www.elasticsearch.org/guide/reference/api/admin-indices-templates/
maybe that feature can help you.

--Alex

On Fri, Jul 12, 2013 at 11:38 PM, Paul Bellora bell...@gmail.comwrote:

I have a property that is common to all my document types. I would now
like to apply a custom mapping to this property across an entire index. I
can't use default-mapping.json because that's applied to all indexes and I
need to be able to support different versions of mappings between indexes.
Is there any other way to specify a mapping for a common property, other
than explicitly repeating it for each type in my index creation api call? I
have numerous types and want to avoid that level of verbosity if possible.

--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearc...@**googlegroups.com.

For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit https://groups.google.com/d/**
topic/elasticsearch/**nw4LTAmkmPs/unsubscribehttps://groups.google.com/d/topic/elasticsearch/nw4LTAmkmPs/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
elasticsearc...@**googlegroups.com.

For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/nw4LTAmkmPs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Hey Paul,
you're on the right track, you only missed the type if your foo field, I guess it should be "type":"string". You're mapping should be ok then, you don't necessarily need to use the file based configuration.

Cheers
Luca

On 17 Jul 2013, at 21:30, Paul Bellora bellorap@gmail.com wrote:

Interesting - the concept is exactly what I'm looking for. Unfortunately it can't be applied in the way I'd hoped:

curl -X PUT localhost:9200/test -d '{
"mappings" : {
"default" : {
"properties" : {
"foo" : { "index" : "unanalyzed" }
}
}
}
}'

This yields:

MapperParsingException[mapping [default]]; nested: MapperParsingException[No type specified for property [foo]];

The documentation says:

The default mapping definition can be overridden in several manners. The simplest manner is to simply define a file called default-mapping.json and placed it under the config directory (which can be configured to exist in a different location). It can also be explicitly set using the index.mapper.default_mapping_location setting.

So it seems like I would need to make a default mappings file for each index and use the default_mapping_location property to point to it. This is enough of an inconvenience to my reindexing workflow that I think I'll just stick to the verbose index settings. Thanks for the suggestions though!

On Tue, Jul 16, 2013 at 7:29 AM, Luca Cavanna cavannaluca@gmail.com wrote:

Hi,
you can use the default type. Have a look here: Elasticsearch Platform — Find real-time answers at scale | Elastic .

The default type is really handy when you have multiple types with a lot of similarities. You may want to avoid duplications, thus you define the common fields once under the default type, which will be applied automatically to all the types that belong to the current index. And of course you can combine it with index templates too.

Cheers
Luca

On Monday, July 15, 2013 5:43:44 PM UTC+2, Paul Bellora wrote:

Hmm, that's interesting but it still appears to define mappings on a per-type basis, at least in that page's examples. Is there a way I can leverage index templates to define mappings across all types in the index?

On Mon, Jul 15, 2013 at 2:20 AM, Alexander Reelsen a...@spinscale.de wrote:

Hey

have you seen the index template feature of elasticsearch at Elasticsearch Platform — Find real-time answers at scale | Elastic
maybe that feature can help you.

--Alex

On Fri, Jul 12, 2013 at 11:38 PM, Paul Bellora bell...@gmail.com wrote:

I have a property that is common to all my document types. I would now like to apply a custom mapping to this property across an entire index. I can't use default-mapping.json because that's applied to all indexes and I need to be able to support different versions of mappings between indexes. Is there any other way to specify a mapping for a common property, other than explicitly repeating it for each type in my index creation api call? I have numerous types and want to avoid that level of verbosity if possible.

You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearc...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elasticsearch/nw4LTAmkmPs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elasticsearc...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elasticsearch/nw4LTAmkmPs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elasticsearch/nw4LTAmkmPs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

You can take a look into the following thread, if you are interested into a
dynamic mapping sample:
https://groups.google.com/forum/#!msg/elasticsearch/fIOzYaslI_Q/NMAfS2aDQWoJ

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Oh that was silly of me - I should've read the error more carefully. And I
even wrote unanalyzed instead of not_analyzed!. This worked like a charm:

curl -X PUT localhost:9200/test -d '{
"mappings" : {
"default" : {
"properties" : {
"foo" : { "index" : "not_analyzed", "type" : "string" }
}
}
}
}'

Thanks for your help!

On Wed, Jul 17, 2013 at 4:13 PM, Luca Cavanna cavannaluca@gmail.com wrote:

Hey Paul,
you're on the right track, you only missed the type if your foo field, I
guess it should be "type":"string". You're mapping should be ok then, you
don't necessarily need to use the file based configuration.

Cheers
Luca

On 17 Jul 2013, at 21:30, Paul Bellora bellorap@gmail.com wrote:

Interesting - the concept is exactly what I'm looking for. Unfortunately
it can't be applied in the way I'd hoped:

curl -X PUT localhost:9200/test -d '{
"mappings" : {
"default" : {
"properties" : {
"foo" : { "index" : "unanalyzed" }
}
}
}
}'

This yields:

MapperParsingException[mapping [default]]; nested:
MapperParsingException[No type specified for property [foo]];

The documentation says:

The default mapping definition can be overridden in several manners. The
simplest manner is to simply define a file called default-mapping.json and
placed it under the config directory (which can be configured to exist in
a different location). It can also be explicitly set using the
index.mapper.default_mapping_location setting.

So it seems like I would need to make a default mappings file for each
index and use the default_mapping_location property to point to it. This
is enough of an inconvenience to my reindexing workflow that I think I'll
just stick to the verbose index settings. Thanks for the suggestions though!

On Tue, Jul 16, 2013 at 7:29 AM, Luca Cavanna cavannaluca@gmail.comwrote:

Hi,
you can use the default type. Have a look here:
Elasticsearch Platform — Find real-time answers at scale | Elastic .

The default type is really handy when you have multiple types with a
lot of similarities. You may want to avoid duplications, thus you define
the common fields once under the default type, which will be applied
automatically to all the types that belong to the current index. And of
course you can combine it with index templates too.

Cheers
Luca

On Monday, July 15, 2013 5:43:44 PM UTC+2, Paul Bellora wrote:

Hmm, that's interesting but it still appears to define mappings on a
per-type basis, at least in that page's examples. Is there a way I can
leverage index templates to define mappings across all types in the index?

On Mon, Jul 15, 2013 at 2:20 AM, Alexander Reelsen a...@spinscale.dewrote:

Hey

have you seen the index template feature of elasticsearch at
http://www.elasticsearch.org/guide/reference/api/admin-
indices-templates/http://www.elasticsearch.org/guide/reference/api/admin-indices-templates/
maybe that feature can help you.

--Alex

On Fri, Jul 12, 2013 at 11:38 PM, Paul Bellora bell...@gmail.comwrote:

I have a property that is common to all my document types. I would now
like to apply a custom mapping to this property across an entire index. I
can't use default-mapping.json because that's applied to all indexes and I
need to be able to support different versions of mappings between indexes.
Is there any other way to specify a mapping for a common property, other
than explicitly repeating it for each type in my index creation api call? I
have numerous types and want to avoid that level of verbosity if possible.

--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearc...@**googlegroups.com.

For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit https://groups.google.com/d/**
topic/elasticsearch/**nw4LTAmkmPs/unsubscribehttps://groups.google.com/d/topic/elasticsearch/nw4LTAmkmPs/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
elasticsearc...@**googlegroups.com.

For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/nw4LTAmkmPs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/nw4LTAmkmPs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the
Google Groups "elasticsearch" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/elasticsearch/nw4LTAmkmPs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.