On 28 September 2016 at 15:23, Guillaume Smet <guillaume.s...@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 <yo...@hibernate.org> Hibernate NoORM Team _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
