On 14 déc. 2009, at 13:59, Sanne Grinovero wrote:
> You'll find a better explanation in the papers in your dropbox; in
> short: a date is split in multiple fields, like year-month-day (it's
> doing better actually, I'm keeping it simple) and so the number of
> terms is reduced, making a rangequer
inline answers:
2009/12/14 Emmanuel Bernard :
>
> On 14 déc. 2009, at 11:15, Sanne Grinovero wrote:
>
>> Even though I'm ok with breaking index compatibility,
>> it looks like option "2" will not break compatibility per-se
>> (other features might) as they state the same compression algorithm is
>
On 14 déc. 2009, at 11:15, Sanne Grinovero wrote:
> Even though I'm ok with breaking index compatibility,
> it looks like option "2" will not break compatibility per-se
> (other features might) as they state the same compression algorithm is
> being used, just
> they don't apply it automatically
Even though I'm ok with breaking index compatibility,
it looks like option "2" will not break compatibility per-se
(other features might) as they state the same compression algorithm is
being used, just
they don't apply it automatically anymore (and the Store.Compress
isn't defined in 3.0)
Actuall
2. is not backward compatible index-wsie, is it?
Are we ok to break backward compatibility on indexes?
On 13 déc. 2009, at 23:41, Sanne Grinovero wrote:
> Hi all,
> I'm trying to migrate Hibernate Search to Lucene 2.9;
> As you might now the COMPRESS store option is not supported in 3.0
> so I ha
Hi all,
I'm trying to migrate Hibernate Search to Lucene 2.9;
As you might now the COMPRESS store option is not supported in 3.0
so I had created "HSEARCH-425 Remove support for compressed fields
(support removed in Lucene3)"
but looking better I see now that javadocs state:
[...]
* the new
