This can *absolutely* be fixed in ElasticSearch. It's not a problem
with Lucene, but with how ES data is mapped onto the Lucene data model.
The problem is that types and fields use local names instead of
fully-qualified names. As far as Lucene is concerned, there would be a
field named "user.id
I doubt this issue will ever be "fixed" since the limitation exists in
Lucene. All types belong to the same index and a field's data needs to be
uniform in Lucene's eyes. A document's type is used to indicate different
mappings for a document, but not different ways to segment the data types
in th
Thanks for your comment! Looks like correct github issue to reference is
this one:
https://github.com/elasticsearch/elasticsearch/issues/4081
I've added my comments, and I'm rooting for a solution to this problem
rather than just a warning, which won't really solve the problem for us.
Fingers
This is on the plate. I'm not 100% sure exactly what the fix will be but it
could be something along the lines of a warning when a mapping is
introduced with the same field name but different types.
--
You received this message because you are subscribed to the Google Groups
"elasticsearch" gr
Are there any ES committers on the mailing list who wouldn't mind
commenting on this issue?
If I have two different types "user" and "session", and both of them have
and "id" field, shouldn't ElasticSearch understand that those are two
different fields, and that their fully-qualified names are
Yes, you guys are right. There are multiple different types in this index,
and some of them have LONG ids, while others have INTEGER or STRING ids.
I'll have to redesign a few parts of the mappings to fix that problem.
I suppose the same restriction applies across nested types as well, right?
I
Like Alex mentioned, I would check all the mappings to ensure the types of
the id field are all the same (doesn't matter what the value is in it -
what matters is the type defined in the mapping). Your error message means:
in one type the id field is long (in the mapping), and in the other type
Hey,
is there a complete stack trace in the elasticsearch log files available
you could post here?
Also, your query is only spanning one index and one type? If not can you
provide other mappings? (I dont think this is an issue here, when you say
that optimizing it down to one segment makes it work
Hello hello! I have a bizarre error I've been trying to debug for a few
weeks with no luck, and I'm finally left to conclude that it may be a bug
in ElasticSearch.
Once every few days, I start seeing shard failures in my query results,
like this:
{
"index": "my_index",
"shard": 3,
