I've sent a pull request:
https://github.com/hibernate/hibernate-search/pull/887
Davide
On Mon, Aug 10, 2015 at 1:20 PM, Hardy Ferentschik
wrote:
> On Mon, Aug 10, 2015 at 12:34:33PM +0100, Davide D'Alto wrote:
> > I'm not sure there is an easy way to convert Instant and DateTime to a
> > num
On Mon, Aug 10, 2015 at 12:34:33PM +0100, Davide D'Alto wrote:
> I'm not sure there is an easy way to convert Instant and DateTime to a
> numeric value.
> The problem is that the resolution for temporal types is nanoseconds, the
> following datetime is valid:
>
> year: -999.999.999
> month: 12
> d
On 10 August 2015 at 12:16, Gunnar Morling wrote:
>> With these new types,backwards compatibility is a non-issue. So unless
>> someone makes a strong case for needing these as String in the index,
>> what about we drop some complexity?
>
> ElasticSearch uses Strings for transferring dates in JSON
I'm not sure there is an easy way to convert Instant and DateTime to a
numeric value.
The problem is that the resolution for temporal types is nanoseconds, the
following datetime is valid:
year: -999.999.999
month: 12
day: 31
hour: 23
minute: 59
second: 59
nanos: 999.999.999
It gets more complica
> With these new types,backwards compatibility is a non-issue. So unless
> someone makes a strong case for needing these as String in the index,
> what about we drop some complexity?
ElasticSearch uses Strings for transferring dates in JSON structures
(see
https://www.elastic.co/guide/en/elastics
On 10 August 2015 at 11:04, Hardy Ferentschik wrote:
> Hi,
>
> sorry, I am late to the game, but I here are some more thoughts on this.
>
> I think the consensus so far is that
>
> # Date/time types which represent an instant in time are treated as usual.
> They can be string encoded (per defau
Hi,
sorry, I am late to the game, but I here are some more thoughts on this.
I think the consensus so far is that
# Date/time types which represent an instant in time are treated as usual.
They can be string encoded (per default MMddHHmmssSSS) or numerically
in which case the numeric l
On 5 August 2015 at 17:22, Davide D'Alto wrote:
>> Proposal: use numeric but still - rather than taking the milliseconds
>> from epoch, take the resulting number from MMDD ?
>
> I don't think I understand what you mean with "the resulting number from
> MMDD".
> Wouldn't be similar to get t
> Proposal: use numeric but still - rather than taking the milliseconds
> from epoch, take the resulting number from MMDD ?
I don't think I understand what you mean with "the resulting number from
MMDD".
Wouldn't be similar to get the number of days from epoch?
But basically, you are sayi
On 5 August 2015 at 16:27, Gunnar Morling 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 de
> 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
Inline:
On 5 August 2015 at 15:42, Davide D'Alto 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)
>
> 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
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 wrote:
> > What would you do though in case of the following:
> >
> > @D
2015-08-05 12:41 GMT+02:00 Sanne Grinovero :
> 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 LocalDat
On 5 August 2015 at 14:29, Davide D'Alto 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
> 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.
On
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 java
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+
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 num
20 matches
Mail list logo
