> Gunnar, the direct HQL->ES-QL work is not as trivial as it seems. I don’t
> think ElasticSearch can search on fields that are not explicitly indexed.
> (Jiri correct me if I’m wrong). So we would need to guess or anticipate
> which field wants to be indexed and how “transparently”. Not the best of
> settings.
This is correct, you cannot search on fields that are not indexed. You can
of course store them, but cannot perform queries on them.
Interesting, I really need to take a closer look at ES and its APIs.
How does it react when searching on an un-indexed field? If we can detect
the situation and raise a meaningful exception indicating that an index is
missing so a given query can't be run (could even be done during start-up
for named queries), then I'd say that's good enough, at least for a first
iteration? In particular if we add support for @Index so a user can react.
As said that solution would only be a work-around until we can delegate
that task to HSearch (which then would have the same challenge probably).
When search on an un-indexed field, Elasticsearch will not raise any notice, warning,
error, nothing. It will just not match and therefore returns empty result. However, you
can find out if the field is indexed by reading it from mapping [1]. Therefore, you are
able to detect this situation.
Jirka
[1]
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/ind...