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)
Actually option "1" (dropping support for Compression) would break it,
in case you are
having compressed field.
The numbers/dates indexing and new rangequeries will force us to drop
backwards compatibility,
unless we implement those later on keeping the old broken strategy.
2009/12/14 Emmanuel Bernard <emman...@hibernate.org>:
> 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 had created "HSEARCH-425 Remove support for compressed fields
>> (support removed in Lucene3)"
>>
>> but looking better I see now that javadocs state:
>>
>> [...]
>> * the new way to achieve this is: First add the field
>> indexed-only (no store)
>> * and additionally using the same field name as a binary, stored field
>> * with {...@link CompressionTools#compressString}.
>>
>> So I was wrong as we actually have two options:
>> 1) drop support deprecating the COMPRESS enum value
>> 2) implement the new strategy as suggested by Lucene's developers
>>
>> I'm assuming you all would agree on 2) ?
>> If so I'll rename HSEARCH-425 to "Reimplement support for compressed
>> fields in Lucene3"
>>
>> Cheers,
>> Sanne
>> _______________________________________________
>> 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
