On 5 August 2015 at 14:29, Davide D'Alto <dav...@hibernate.org> wrote:
>> wouldn't use NumericField(s) in this case, as they are more
>> effective only with larger ranges, while MM and DD are very short;
>
>
> I'm ok with that, it just that the @DateBridge annotation allows to choose
> the encoding
> and it would sound strange not to enable this annotation for this type.
Keep in mind that the Resolution attribute of @DateBridge provides
several choices which don't make sense with a LocalDate, as the value
object doesn't have a time or milliseconds range.
In some ways our @DateBridge was necessary to deal with the
limitations of Date, which was a very generic vessel.
What do you suggest we do if a user maps the following?
@DateBridge(resolution=MILLISECOND)
LocalDate birthday;
Thanks,
Sanne
> On Wed, Aug 5, 2015 at 11:41 AM, Sanne Grinovero <sa...@hibernate.org>
> wrote:
>
>> 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.
>>
>> 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.
>>
>> -- 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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
