Hi,
I think a great solution for that would be to leverage "annotation
composition" as done e.g. in CDI and Bean Validation.
There would be an annotation @DocValuesField which will cause the creation
of a DocValues and which would expose attributes required for its
configuration:
@DocValuesF
Hi,
Note: I am no core developer of Hibernate Search, but I am currently working on
something
that looks quite similar to what you are doing :). One part of it is an
updating mechanism based on triggers
that uses the database as a event-storage as well. It's not the exact same
thing, but relat
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+
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
> 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
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
Ok, I am changing my mind ImplicitNamingStratregy as well. Gail's
"annotation javadoc" argument swayed me. I have already changed the
defaults for keyword-auto-quoting (to false) and use-new-generator-mappings
(to true). I will add a change for the default ImplicitNamingStratregy as
well for CR4
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
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
> 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
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)
>
> 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
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
> 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
ot a
whole number and you'd have to apply rounding which is timezone
specific.
By simply encoding the number in the above format, you'd encode today
as the number "20150805".
That's a whole number which avoids the timezone relativity and can be
efficiently encoded in numeric fo
Hi Martin
For this version the AbstractDatabaseHibernateSearchController is not able
to process Lucene workers simultaneously. When we build it our initial
requirement was only one node should process the workers at a time, but the
“master” was floating. We use Quartz to get this type of functiona
http://in.relation.to/2015/08/05/hibernate-orm-500-cr4-release/
Mainly changes in the defaults for some settings in prep for Final
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Hi Flemming,
welcome on this list!
I waited a bit to reply myself, as you already know I like the
proposal. Unfortunately many others are on holidays, so other feedback
might be slow.
Still I wouldn't let that slow you down and start the works for
merging it; I already anticipated over chat that
Please don't push anything to 4.3 branch until I'm finished with the
release.
Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
I will blog and send out announcements on Thursday.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
20 matches
Mail list logo
