[hibernate-dev] HSEARCH-2358 "fields" attribute in Elasticsearch search results is being ignored

[Guillaume Smet]

Hi Yoann,

On Wed, Sep 28, 2016 at 2:56 PM, Yoann Rodiere <yoann at hibernate.org> wrote:

> I'd be in favor of 1, which seems more rational to me. It only has one
> downside: if we go on with this approach, Calendar values (and
> ZonedDateTime, ZonedTime, etc.) will have to be stored as String, not as
> Date, since Elasticsearch doesn't store the timezone, just the UTC
> timestamp. We're currently working this around by inspecting the "_source",
> which contains the original timezone (since it's just the raw, originally
> submitted JSON).
>
> What do you think?
>

I'm not sure you completely understood the consequences of storing dates as
strings.

You won't be able to use these sorts of features:
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-datehistogram-aggregation.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-daterange-aggregation.html
which are used very often when dealing with dates.

I don't think storing dates as strings is a viable alternative.

IMHO, the choice is between:
- using _source as we currently do it. I'm not sure allowing people to
directly inject data into Elasticsearch and bypass Hibernate Search is
something we can support in the long run so I think it would be acceptable
if we document that we don't expect people to index documents directly (or
at least that they should carefully follow the HS indexing format - which
looks like an acceptable thing).
- using fields and be aware that we will get back UTC values from
projections on these fields

-- 
Guillaume