-
Notifications
You must be signed in to change notification settings - Fork 24.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mapping not working #11
Comments
There is a bug in the docs (which I just fixed), the url for it should be http://localhost:9200/twitter/tweet/_mapping. Here is the example:
You first need to create the index explicitly to add mappings. I will add another issue so the index will be created automatically in this case.
Not sure that I understand why its ambiguous? The indexable content can have the type as the first level JSON field, but its optional (since the type already exists in the url and I can derive it from that).
Mappings are basically meta data on how to map the indexable JSON content of a type into the search engine. You can have more than one type, and each type can optionally have mapping defined for it. |
Create mapping now will automatically create the indices by default, see #12. |
OK, so there is one mapping per index+type. Gotcha. The reason that including the mapping name in the JSON is ambiguous is because of object type mappings. Without a predefined mapping, you don't know if the top level 'tweet' key is a mapping name, or the first key in the object being stored. So either you have to always specify the mapping, so the second case would look like:
or never specify the mapping in the JSON, and just use the 'type' from the URL as the mapping name (which would be my preference) |
Yes, you are correct about the possible problem there. The reason I added the support for that is to simplify working json converters in different languages, which usually add the "type" as the outermost JSON object. Do you think it was a mistake? |
I think that having it as either-or is a mistake, yes. Not sure which is the better interface though. My feeling (having just written a Perl interface to ElasticSearch) is that you have to generate the URL and the JSON anyway, and it looks more consistent to me to specify the type in the URL, and the data in the JSON. But as I say, it makes little difference to me which version you settle on. |
Let me think about it a bit more. The only case where it will break is if the case you noted, (JSON object with the type name, and another JSON object with the same type name) and I am not sure if people will ever generate a JSON like that. I like the ability to try and support both... |
That said, we don't have any test yet :-) Closes #11.
Closes #11. (cherry picked from commit 8a87054)
NPE fix for in or, and and not filters
…stalled version if es_version_lock is set to true. Closes elastic#11
…ions_fix_indexing Fix indexing
Fixes elastic/elasticsearch-internal#497 Fixes ESQL-560 A query like `from test | sort data | limit 2 | project count` fails because `LocalToGlobalLimitAndTopNExec` planning rule adds a collecting `TopNExec` after last GATHER exchange, to perform last reduce, see ``` TopNExec[[Order[data{f}#6,ASC,LAST]],2[INTEGER]] \_ExchangeExec[GATHER,SINGLE_DISTRIBUTION] \_ProjectExec[[count{f}#4]] // <- `data` is projected away but still used by the TopN node above \_FieldExtractExec[count{f}#4] \_TopNExec[[Order[data{f}#6,ASC,LAST]],2[INTEGER]] \_FieldExtractExec[data{f}#6] \_ExchangeExec[REPARTITION,FIXED_ARBITRARY_DISTRIBUTION] \_EsQueryExec[test], query[][_doc_id{f}#9, _segment_id{f}#10, _shard_id{f}#11] ``` Unfortunately, at that stage the inputs needed by the TopNExec could have been projected away by a ProjectExec, so they could be no longer available. This PR adapts the plan as follows: - add all the projections used by the `TopNExec` to the existing `ProjectExec`, so that they are available when needed - add another ProjectExec on top of the plan, to project away the originally removed projections and preserve the query semantics This approach is a bit dangerous, because it bypasses the mechanism of input/output resolution and validation that happens on the logical plan. The alternative would be to do this manipulation on the logical plan, but it's probably hard to do, because there is no concept of Exchange at that level.
With this commit we embed Kibana dashboards for nightly and release benchmarks. As we want to gather further feedback we did not yet remove the old functionality based on dygraphs (this will happen in elastic#33). Closes elastic#23 Closes elastic#9 Closes elastic#11 Closes elastic#12
Hiya
Following the examples in your docs, create-mapping does not seem to work, eg:
I tried creating the index first, but same thing.
Also, the JSON format for specifying the mapping type to use when indexing a document is ambiguous, eg:
Does that mean that the document has mapping type 'tweet', or that there is no mapping type specified, and it has a single top level key called 'tweet'.
And one thing i'm not sure about? Is a mapping the same thing as a type? So you would never have type 'foo' and mapping 'bar'?
thanks
Clint
The text was updated successfully, but these errors were encountered: