On 28 September 2016 at 15:23, Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
You won't be able to use these sorts of features:
https://www.elastic.co/guide/en/elasticsearch/reference/curr
ent/search-aggregations-bucket-datehistogram-aggregation.html
https://www.elastic.co/guide/en/elasticsearch/reference/curr
ent/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.
Right. I didn't know about these.
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
... and the latter is a no-go for ZonedDate et al., since the point of
those classes is to preserve timezone/offset.
Maybe we could just use "_source" when we really need to, but I doubt
there's an elegant way to do this, so I guess we'd better not.
Anyway, it seems we're down to only one acceptable solution... Unless
anyone has another view on all this, I'll index ZonedDate/etc. as dates and
use "_source" for value retrieval, and I'll close HSEARCH-2358 as
"Won't
fix".
Thanks for the insight!
Yoann Rodière <yoann(a)hibernate.org>
Hibernate NoORM Team