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 anymore (and the Store.Compress
isn't defined in 3.0)
So today (2.4) they use a binary format to store the compressed data?
Actually option "1" (dropping support for Compression)
would break it,
in case you are
having compressed field.
right unless we simulate what they did before exactly.
What's the rational for dropping the support on their side?
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.
You lost me, what is that?