> 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 <sa...@hibernate.org> wrote:
> On 5 August 2015 at 16:27, Gunnar Morling <gun...@hibernate.org> 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 <sa...@hibernate.org>:
> >>
> >> Inline:
> >>
> >> On 5 August 2015 at 15:42, Davide D'Alto <dav...@hibernate.org> 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 <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.
> >>
> >> 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 <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
> >> _______________________________________________
> >> 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
