elasticsearch.ProjectionConstants exposes Lucene constructs


By inheritance, elasticsearch.ProjectionConstants exposes impossible things:

  • DOCUMENT: it's a Lucene document but that's not available and can be confused with SCORE: should we remove SCORE and map DOCUMENT to SCORE for the es backend?

  • DOCUMENT_ID: does ES expose a document id?

  • EXPLANATION: does Expose an explanation object? Same type as Lucene's?




Gunnar Morling
May 3, 2016, 9:03 AM

I wouldn't bother too much about this. +1 for strictly separating the two interfaces, as it will take away "wrong" constants from auto-completion. This should be fine to address most common usage mistakes.

Sanne Grinovero
May 3, 2016, 11:01 AM

Ok, let's go for the separation for our first Elasticsearch supporting release, but my question about how this API could be better stands for version 6 .. in case any of you have ideas I opened to see if something could be done.

Emmanuel Bernard
May 4, 2016, 9:05 AM

Some meta comment. In the grand scheme of better output for the current people working on the project, we probably should not focus too much on nice details and settle for good enough. I'm the first to be saddened by a non type-safe approach but we know it costs several days of engineering to reach this at the very list. Damn economics!

Gunnar Morling
May 4, 2016, 9:17 AM

Ack. Let's keep the fur on this yak and shave it another day.

Sanne Grinovero
May 4, 2016, 9:22 AM

Sure but this is no different than what I already planned: is scheduled for 6, and wasn't proposing it as a blocker.

It's just an invitation to comment on that issue, if you happen to have a good idea.


Gunnar Morling


Emmanuel Bernard



Suitable for new contributors


Feedback Requested



Fix versions

Affects versions