Hi Yoann, On Wed, Sep 28, 2016 at 2:56 PM, Yoann Rodiere <yo...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
