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

as I'd like us to consider not

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&gt; >> 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