Re: [hibernate-dev] HSEARCH-2358 "fields" attribute in Elasticsearch search results is being ignored
Hi Yoann,
On Wed, Sep 28, 2016 at 2:56 PM, Yoann Rodiere <yoann(a)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-ag...
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-ag...
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