If a user select a resolution that does not make much sense we can log a
warning.
But I think this might make sense:
@DateBridge(resolution=MONTH)
LocalDate birthday;
On Wed, Aug 5, 2015 at 3:37 PM, Davide D'Alto <dav...@hibernate.org> 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.
>
> +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)
>
> It is equivalent to:
> LocalDateTime dateTime = date.atStartOfDay( ZoneOffset.UTC );
>
>
>
>
>
>
>
>
>
>
> On Wed, Aug 5, 2015 at 3:24 PM, Gunnar Morling <gun...@hibernate.org>
> wrote:
>
>>
>>
>> 2015-08-05 12:41 GMT+02:00 Sanne Grinovero <sa...@hibernate.org>:
>>
>>> 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 <gun...@hibernate.org> 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 <dav...@hibernate.org>:
>>> >
>>> >> 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@lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev@lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
