I installed Elasticsearch 1.5.2 on CentOS as a service.
I tried to add mappings using PUT:
curl -XPUT $ES_HOST/my_index -d'
{
"mappings": {
"my_type": {
"properties": {
"field": {
"type": "nested"
}
}
}
}
}'
That request works fine and creates new index with correct mappings.
Instead of putting mappings manually I want to store mappings on server in config files. For that I created file /etc/elasticsearch/mappings/my_index/all_mappings.json with the same content as previous request body. After that I'm trying to create index curl -XPUT $ES_HOST/my_index but the error occurs
{
"error": "MapperParsingException[mapping [all_mappings]]; nested:
MapperParsingException[Root type mapping not empty after parsing!
Remaining fields: [mappings : {my_type={properties={field={type=nested}}}}]]; ",
"status": 400
}
I tried to remove mappings field in config json but nothing changed.
The name of the file is the mapping name. So, for /mappings/my_index/all_mappings.json you should have the index my_index and the type called all_mappings.
Also, the content of the file should be:
{
"properties": {
"field": {
"type": "nested"
}
}
}
These being said, do the following:
create a my_type.json file under /etc/elasticsearch/mappings/my_index folder
put inside that file the following:
{
"properties": {
"field": {
"type": "nested"
}
}
}
call PUT /test_my_index
check the mapping: GET /test_my_index/_mapping
Related
I'm trying to create an autocomplete index for my elasticsearch using the search_as_you_type datatype.
My first command I run is
curl --request PUT 'https://elasticsearch.company.me/autocomplete' \
'{
"mappings": {
"properties": {
"company_name": {
"type": "search_as_you_type"
},
"serviceTitle": {
"type": "search_as_you_type"
}
}
}
}'
which returns
{"acknowledged":true,"shards_acknowledged":true,"index":"autocomplete"}curl: (3) nested brace in URL position 18:
{
"mappings": {
"properties": etc.the rest of the json object I created}}
Then I reindex using
curl --silent --request POST 'http://elasticsearch.company.me/_reindex?pretty' --data-raw '{
"source": {
"index": "existing_index"
},
"dest": {
"index": "autocomplete"
}
}' | grep "total\|created\|failures"
I expect to see some "total":1000,"created":5etc but some kind of response from the terminal, but I get nothing. Also, when I check the mapping of my autocomplete index, by running curl -u thething 'https://elasticsearch.company.me/autocomplete/_mappings?pretty',
I get an empty mapping result:
{
"autocomplete" : {
"mappings" : { }
}
}
Is my error in the creation of my index or the reindexing? I'm expecting the autocomplete mappings to show the two fields I'm searching for, ie: "company_name" and "serviceTitle". Any ideas how to fix?
I’m trying to create an index in elasticsearch using kibana dev tools but i’m facing the following errors.please suggest me on this.
PUT xyz
{
“mappings”:{
“abc”:{
“type”:”nested”,
“properties”:{
“name”:{“type”:”keyword”}
}
}
}
}
Error:
{
type:”mapper_parsing_exception”,
reason:”Root mapping definition has unsupported parameters:[type:nested]
}
It was working fine elasticsearch 7 but not in version 6.4.2
This is because in ES 7, mapping types have been removed.
If you want to make this work on ES 6.4.2, you need to change your query to include a mapping type name, like this:
PUT xyz
{
"mappings": {
"type_name": { <---- add this
"properties": { <---- and this
"abc": {
"type": "nested",
"properties": {
"name": {
"type": "keyword"
}
}
}
}
}
}
}
When I create an index with mapping like this one, what does it mean the _template/ word? what does the _ mean? I ask your help to understand more about creating an index, are they stored in a kind of folder, like template/packets folder?
PUT _template/packets
{
"template": "packets-*",
"mappings": {
"pcap_file": {
"dynamic": "false",
"properties": {
"timestamp": {
"type": "date"
},
"layers": {
"properties": {
"frame": {
"properties": {
"frame_frame_len": {
"type": "long"
},
"frame_frame_protocols": {
"type": "keyword"
}
}
},
"ip": {
"properties": {
"ip_ip_src": {
"type": "ip"
},
"ip_ip_dst": {
"type": "ip"
}
}
},
"udp": {
"properties": {
"udp_udp_srcport": {
"type": "integer"
},
"udp_udp_dstport": {
"type": "integer"
}
}
}
}
}
}
}
}
}
I ask this because after typing this, I recieve he following error
! Deprecation: Deprecated field [template] used, replaced by [index_patterns]
{
"acknowledged": true
}
I copied the pattern from this link:
https://www.elastic.co/blog/analyzing-network-packets-with-wireshark-elasticsearch-and-kibana
And I'm trying to do exactly what is taught in the link, and I already can capture files with tshark and parse copy them into a packets.json file, and I will use filebeat to transfer the data to Elasticsearch, I already uploaded some data to Elasticsearch, but it wasn't indexed correctly, I just saw a lot of information with a lot of data.
My aim is to inderstand exactly how to create a new index pattern, and also how to relate what I upload to that index.
Thank you very much.
Just replace word template with index_patterns:
PUT _template/packets
{
"index_patterns": ["packets-*"],
"mappings": {
...
Index templates allow you to define templates that will automatically be applied when new indices are created.
After version 5.6 the format of Elasticsearch index templates has changed; the template field, which was used to specify one or more patterns for matching index names that would use the template at create time, was deprecated and superseded by the more appropriately named field index_patterns which works exactly the same way.
To solve the issue and get rid of the deprecation warnings you will have to update all your pre-6.0 index templates, changing the template to index_patterns.
You can list all your index templates by running this command:
curl -XGET 'http://localhost:9200/_template/*?pretty'
Or replace the asterisk with the name of one specific index template.
More about ES templates is here.
I have an index with a field called loc which is correctly mapped as a geopoint.
When running a search like:
curl -XGET 'http://localhost:9200/DB/_search'
I get 10 or so results and all of them appear to have loc inside the _source object.
If I try:
curl -XGET 'http://localhost:9200/DB/_search?fields=name'
I get a fields object with the name field correctly set up (name exists, it is another field, it is a string). Thing is, if I try the same thing with the loc field, as in:
curl -XGET 'http://localhost:9200/DB/_search?fields=loc'
I don't get anything back, neither the _source nor the fields objects.
How may I return the loc field when running this query?
Bonus question: Is there a way to return the loc field as a geohash?
Update, here's the mapping:
{
"geonames": {
"mappings": {
"place": {
"properties": {
"ele": {
"type": "string"
},
"geoid": {
"type": "string"
},
"loc": {
"type": "geo_point"
},
"name": {
"type": "string"
},
"pop": {
"type": "string"
},
"tz": {
"type": "string"
}
}
}
}
}
}
You should use source filtering instead of fields and you'll get the loc field as you expect.
curl -XGET 'localhost:9200/DB/_search?_source=loc'
Quoting from the official documentation on fields (emphasis added):
The fields parameter is about fields that are explicitly marked as stored in the mapping, which is off by default and generally not recommended. Use source filtering instead to select subsets of the original source document to be returned.
I recently updated an ElasticSearch server of ours from version 0.9 to 1.4, and when I imported a Mapping for the new ES, I saw this was added in the mapping:
"query": {
"properties": {
"match_all": {
"type": "object"
}
}
},
That snippet isn't in the mapping that I imported, but it always appears when I query curl -X GET localhost:9200/my_index/_mapping?pretty.
Has anyone else seen this?
It looks like you accidentally created the index rather than querying it. IE, you posted to:
POST http://localhost:9200/myindex -d '"query": {
"properties": {
"match_all": {
"type": "object"
}
}
}'
which would create the index with that mapping, when you probably wanted:
POST http://localhost:9200/myindex/_search -d '"query": {
"properties": {
"match_all": {
"type": "object"
}
}
}'
which would just search.