[hibernate-dev] [SEARCH] Remove support for (or deprecate) date/calendar resolution?

Guillaume Smet guillaume.smet at gmail.com
Mon Jan 9 06:53:21 EST 2017


Hi,

On Thu, Jan 5, 2017 at 5:20 PM, Yoann Rodiere <yoann at hibernate.org> wrote:

> That's a catchy subject, now I'm sure I got Guillaume's (angry) attention
> :)
>
> Sanne wanted us to think about feature removal... Here's a proposal.
>
> The feature I'd like to deprecate/remove: automatic truncation of
> date/calendars to a given resolution. It's used like that:
>

Yeah, as you can imagine, I'm pretty reluctant to the idea of removing this
feature. We used it a lot at OW and I'm sure it's pretty widespread out
there (and even when we didn't use HS but Solr, we needed an equivalent
feature). Using range queries is a solution but it's a bit cumbersome for
such a common requirement.

I agree the current behavior might lead to unexpected results. To be
honest, I think we should simply ignore the timezone when truncating. I
mean, when I want to index at a day resolution, I want to index the user
facing day, not the one in the server time zone or in GMT.

So for instance, for 2016-01-01T00:00:00+01:00, I would index 2016-01-01,
not 2015-12-31.

So, as long as the resolution is less precise than day included, what I
would do is in fact remove our call to DateTools.round and have something
like:
- create a GMT GregorianCalendar
- don't set the calendar value using the time in millis but with the
original fields from the calendar passed in parameter (or 0/1 depending on
the resolution)
- index this value

I think this new behavior would fix most of the issues you mention. And if
you really need the behavior when dates in one time zone might be a
different date in a different time zone, then you definitely wouldn't use
the resolution option and stick to the full date with range queries.

So I agree the current behavior is probably not what user expects but I
think it has value.

I would pay to see your face while reading this email :).

-- 
Guillaume


More information about the hibernate-dev mailing list