Re: [hibernate-dev] [Hibernate Search] DocValues and Sorting API -> new mapping annotations ?

2015-08-18 Thread Hardy Ferentschik
On Tue, Aug 18, 2015 at 08:59:28AM +0200, Gunnar Morling wrote: > >> One possible workaround is to enforce the indexNullAs value to match the > >> underlying field type, at the > >> moment it is always a string. > > > > Interesting idea, but the user would need to provide which "value" > > he's ok

Re: [hibernate-dev] [Hibernate Search] DocValues and Sorting API -> new mapping annotations ?

2015-08-18 Thread Gunnar Morling
2015-08-11 0:18 GMT+02:00 Sanne Grinovero : >> One possible workaround is to enforce the indexNullAs value to match the >> underlying field type, at the >> moment it is always a string. > > Interesting idea, but the user would need to provide which "value" > he's ok to give up, as he would need to

Re: [hibernate-dev] [Hibernate Search] DocValues and Sorting API -> new mapping annotations ?

2015-08-11 Thread Gustavo Fernandes
> On 10 Aug 2015, at 23:18, Sanne Grinovero wrote: > > On 7 August 2015 at 13:31, Gustavo Fernandes > wrote: >> On Fri, Aug 7, 2015 at 1:14 PM, Sanne Grinovero wrote: >>> >>> A quick update on some more exploration on this: >>> it turns out sorting on a NumericF

Re: [hibernate-dev] [Hibernate Search] DocValues and Sorting API -> new mapping annotations ?

2015-08-10 Thread Sanne Grinovero
On 7 August 2015 at 13:31, Gustavo Fernandes wrote: > On Fri, Aug 7, 2015 at 1:14 PM, Sanne Grinovero wrote: >> >> A quick update on some more exploration on this: >> it turns out sorting on a NumericField when this field is also using >> an "indexNullAs" token gets the UninvertingReader approach

Re: [hibernate-dev] [Hibernate Search] DocValues and Sorting API -> new mapping annotations ?

2015-08-07 Thread Gustavo Fernandes
On Fri, Aug 7, 2015 at 1:14 PM, Sanne Grinovero wrote: > A quick update on some more exploration on this: > it turns out sorting on a NumericField when this field is also using > an "indexNullAs" token gets the UninvertingReader approach to throw an > exception. > My two conclusions: > - we need

Re: [hibernate-dev] [Hibernate Search] DocValues and Sorting API -> new mapping annotations ?

2015-08-07 Thread Sanne Grinovero
A quick update on some more exploration on this: it turns out sorting on a NumericField when this field is also using an "indexNullAs" token gets the UninvertingReader approach to throw an exception. My two conclusions: - we need to move away from supporting those tokens in NumericField, especiall

Re: [hibernate-dev] [Hibernate Search] DocValues and Sorting API -> new mapping annotations ?

2015-08-05 Thread Gunnar Morling
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

Re: [hibernate-dev] [Hibernate Search] DocValues and Sorting API -> new mapping annotations ?

2015-08-04 Thread Sanne Grinovero
Hi Guillaume, thanks! great input. Some comments inline: On 4 August 2015 at 15:11, Guillaume Smet wrote: > Hi Sanne, > > On Wed, Jul 29, 2015 at 1:26 PM, Sanne Grinovero > wrote: >> >> I'm not sure if this should be extending the @Field annotation as >> there are special restrictions implied in

Re: [hibernate-dev] [Hibernate Search] DocValues and Sorting API -> new mapping annotations ?

2015-08-04 Thread Guillaume Smet
Hi Sanne, On Wed, Jul 29, 2015 at 1:26 PM, Sanne Grinovero wrote: > I'm not sure if this should be extending the @Field annotation as > there are special restrictions implied in terms of analysis: are we > going to enforce a specific type of tokenizer, or simply take the > analysis option away?

[hibernate-dev] [Hibernate Search] DocValues and Sorting API -> new mapping annotations ?

2015-07-29 Thread Sanne Grinovero
You might remember that running a full-text Query on a field always required some specific care; since the beginning of Hibernate Search the user had to make sure the field was not tokenized, or tokenized but generating a single token. This was a "soft requirement": if you didn't know, you'd get i