Re: [hibernate-dev] HSEARCH Java 8 Date Time

> Proposal: use numeric but still - rather than taking the milliseconds > from epoch, take the resulting number from YYYYMMDD ? I don't think I understand what you mean with "the resulting number from YYYYMMDD". Wouldn't be similar to get the number of days from epoch?

But basically, you are saying that I can use different numeric encoding for different types. Isn't it?

So, for example: java.util.Date, java.util.Calendar and java.time.Instant, java.time.LocalDateTime will use number of miliseconds from epoch java.time.LocalDate: number of days from epoch

java.time.LocalTime: number of nanos in a day

> Ok that works but why write all those zeros in the index, when you can > just write the date. I realize storage is cheap, but still we need to > be careful as the index size affects performance ;-) I don't think we need to store the 0s. If I know the type of the field I already know the the time is 0.

Am I missing something?

On Wed, Aug 5, 2015 at 5:00 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > On 5 August 2015 at 16:27, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > >> as I'd like us to consider not > > applying DateBridge on the new types as it doesn't seem to add much > > practical value. > > > > Ok, that may make sense for types such as LocalDate. But there are types > in > > the new API which - unlike LocalDate - do describe an exact instant on > the > > time line (e.g. ZonedDateTime, Instant). For those IMO it makes sense for > > sure to support both encodings, NUMERIC and STRING (similar to > Date/Calendar > > so far) and thus apply @DateBridge. > > +1 > > > Question is whether/how to index/persist TZ information, for Calendar it > > seems not been persisted in the index so far? > > It's encoding the Calendar's time as distance from epoch, which is a > neutral encoding so you don't need the TZ. > > For the old style Date/Calendar types we always assumed the value was > a point-in-time, unless explicitly opting in for an alternative > encoding. > For example for the "birthday use case" a reasonable setting would > have been String encoding with resolution=DAY, although passing in a > Date instance having the right value (as in right timezone) would have > been user's responsibility.. we simply take the long it's storing and > index that with the requested resolution. > > Sanne > > > > > > > 2015-08-05 17:10 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: > >> > >> Inline: > >> > >> On 5 August 2015 at 15:42, Davide D'Alto <davide(a)hibernate.org&gt; wrote: > >> > If a user select a resolution that does not make much sense we can > log a > >> > warning. > >> > >> +1 And update the javadoc to mention that some resolution values don't > >> apply > >> > >> > But I think this might make sense: > >> > > >> > @DateBridge(resolution=MONTH) > >> > LocalDate birthday; > >> > >> Ok but how often do you think that will be used? > >> Sorry playing devil's advocate here, as I'd like us to consider not > >> applying DateBridge on the new types as it doesn't seem to add much > >> practical value. > >> > >> I agree it's worth a shot, but while going ahead keep in mind that > >> maybe simplifying that is the more elegant solution. > >> > >> > On Wed, Aug 5, 2015 at 3:37 PM, Davide D'Alto <davide(a)hibernate.org&gt; > >> > wrote: > >> > > >> >> > What would you do though in case of the following: > >> >> > > >> >> > @DateBridge > >> >> > LocalDate myDate; > >> >> > > >> >> > encoding() defaults to NUMERIC, so would you a) raise an error, or > b) > >> >> ignore encoding() for LocalDate and friends? Both seem not right to > me. > >> >> I > >> >> think there is nothing wrong with using NUMERIC encoding per-se for > >> >> these > >> >> types. We may recommend STRING but if NUMERIC really is what a user > >> >> wants I > >> >> would let them do so. > >> > >> I'm all for letting the users have the last word, but this is one of > >> those cases in which you don't know if they explicitly want that or > >> simply went with the defaults. > >> > >> Not a big problem as of course the important thing of defaults is that > >> "they work" but I'd really prefer the default to try be the most > >> appropriate encoding, which is not numeric in this case. > >> > >> Proposal: use numeric but still - rather than taking the milliseconds > >> from epoch, take the resulting number from YYYYMMDD ? It might even be > >> the most efficient encoding, as you don't have the drawback of > >> clustering which we would have with a numeric encoding working on the > >> individual fields, and doesn't have the bloat of string encoding. > >> > >> >> > >> >> +1 > >> >> > >> >> > What do you suggest we do if a user maps the following? > >> >> > >> >> > @DateBridge(resolution=MILLISECOND) > >> >> > LocalDate birthday; > >> >> > >> >> > >> >> Nothing really, > >> >> I would just consider a LocalDate the same as a LocalDateTime with > time > >> >> 00:00:000 (UTC time zone) > >> > >> Ok that works but why write all those zeros in the index, when you can > >> just write the date. I realize storage is cheap, but still we need to > >> be careful as the index size affects performance ;-) > >> > >> Sanne > >> > >> >> > >> >> It is equivalent to: > >> >> LocalDateTime dateTime = date.atStartOfDay( ZoneOffset.UTC ); > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> On Wed, Aug 5, 2015 at 3:24 PM, Gunnar Morling <gunnar(a)hibernate.org > > > >> >> wrote: > >> >> > >> >>> > >> >>> > >> >>> 2015-08-05 12:41 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: > >> >>> > >> >>>> Our current implementation converts Date in the long "distance from > >> >>>> epoch" to allow correct range-queries treating each Date as an > >> >>>> instant > >> >>>> in time - allowing a universal sorting strategy. But a LocalDate is > >> >>>> not an instant-in-time. > >> >>>> > >> >>>> A LocalDate is intentionally oblivious of the timezone; as the > >> >>>> javadoc > >> >>>> states, it's useful for birthdays, i.e. symbolic occurrences and > >> >>>> potentially legal matters which don't fit into a universal sorting > >> >>>> model but rather with the local political scene - we would need the > >> >>>> combo {LocalDate, ZoneId} provided to be able to allow sorting > across > >> >>>> different LocalDate - or simply assume that they are all referring > to > >> >>>> the same Zone. > >> >>>> > >> >>> > >> >>> Right, I had the latter in mind and would use UTC for that purpose. > >> >>> > >> >>>> > >> >>>> I think that if the user is using a LocalDate type, he's implicitly > >> >>>> hinting that the timezone is not relevant for the practical use > >> >>>> (possibly even wrong); the most faithful representation would be > the > >> >>>> string form in ISO standard format or to encode the day,month,year > as > >> >>>> independent fields? This last detail depends on how it would be > more > >> >>>> efficient to store & query; probably the String format YYYYMMDD > would > >> >>>> be the most efficient internal representation to allow also correct > >> >>>> sorting. > >> >>>> > >> >>>> I wouldn't use NumericField(s) in this case, as they are more > >> >>>> effective only with larger ranges, while MM and DD are very short; > >> >>>> not > >> >>>> sure if it's worth splitting the year as a NumericField either, as > >> >>>> the > >> >>>> values will likely be strongly clustered in the same range of > "recent > >> >>>> years" - although that might depend on the application but it > doesn't > >> >>>> seem worth the complexity, so I'd index & store as a String > YYYYMMDD. > >> >>>> > >> >>> > >> >>> Agreed that this makes most sense, given the "symbolic" nature of > >> >>> LocalDate. > >> >>> > >> >>> What would you do though in case of the following: > >> >>> > >> >>> @DateBridge > >> >>> LocalDate myDate; > >> >>> > >> >>> encoding() defaults to NUMERIC, so would you a) raise an error, or > b) > >> >>> ignore encoding() for LocalDate and friends? Both seem not right to > >> >>> me. I > >> >>> think there is nothing wrong with using NUMERIC encoding per-se for > >> >>> these > >> >>> types. We may recommend STRING but if NUMERIC really is what a user > >> >>> wants I > >> >>> would let them do so. > >> >>> > >> >>>> > >> >>>> -- Sanne > >> >>>> > >> >>>> > >> >>>> On 5 August 2015 at 11:10, Gunnar Morling <gunnar(a)hibernate.org&gt; > >> >>>> wrote: > >> >>>> > Hi, > >> >>>> > > >> >>>> > What's the motivation for using a different representation in > that > >> >>>> case? > >> >>>> > > >> >>>> > For the sake of consistency, I'd use milli seconds since > 1970-01-01 > >> >>>> across > >> >>>> > the board. Otherwise it'll be more difficult to compare fields > >> >>>> > created > >> >>>> from > >> >>>> > properties of different date types. > >> >>>> > > >> >>>> > --Gunnar > >> >>>> > > >> >>>> > > >> >>>> > 2015-08-04 19:49 GMT+02:00 Davide D'Alto <davide(a)hibernate.org&gt;: > >> >>>> > > >> >>>> >> Hi, > >> >>>> >> I started to work on the creation of the bridges for the classes > >> >>>> >> in > >> >>>> the > >> >>>> >> java.time package. > >> >>>> >> > >> >>>> >> I was wondering if we want to convert the values to long using > the > >> >>>> existing > >> >>>> >> approach we have now for java.util.Date. > >> >>>> >> > >> >>>> >> In Hibernate Search a java.util.Date is converted into a long > that > >> >>>> >> represents the number of milliseconds since January 1, 1970, > >> >>>> >> 00:00:00 > >> >>>> GMT > >> >>>> >> using getTime(). > >> >>>> >> > >> >>>> >> The same value can be obtain from a java.time.LocaDate via: > >> >>>> >> > >> >>>> >> long epochMilli = date.atStartOfDay( ZoneOffset.UTC > >> >>>> >> ).toInstant().toEpochMilli(); > >> >>>> >> > >> >>>> >> LocalDate has a method that returns the same value expressed in > >> >>>> number of > >> >>>> >> days: > >> >>>> >> > >> >>>> >> long epochDay = date.toEpochDay(); > >> >>>> >> > >> >>>> >> > >> >>>> >> I would use the second approach > >> >>>> >> > >> >>>> >> Davide > >> >>>> >> _______________________________________________ > >> >>>> >> hibernate-dev mailing list > >> >>>> >> hibernate-dev(a)lists.jboss.org > >> >>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >>>> >> > >> >>>> > _______________________________________________ > >> >>>> > hibernate-dev mailing list > >> >>>> > hibernate-dev(a)lists.jboss.org > >> >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> >>>> > >> >>> > >> >>> > >> >> > >> > _______________________________________________ > >> > hibernate-dev mailing list > >> > hibernate-dev(a)lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev