Re: [hibernate-dev] use_compound_file
Oh I totally forgot about .indexwriter.
OK so here is how it will be
we keep hibernate.search.[indexname].indexwriter.transaction/batch for
most with batch inheriting tx
And we support
hibernate.search.[indexname].indexwriter.use_compound_file
hibernate.search.[indexname].indexwriter.max_field_length
At least that's what in the book now :)
On Nov 13, 2008, at 05:48, Sanne Grinovero wrote:
2 answers inline:
2008/11/13 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> Plus it seems the default value is compound = true, just like in
> Lucene.
> This is not what we are saying in the doc.
> Am I completely off-base?
No, you are correct.
2008/11/12 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> So where would we put these?
> under hibernate.search.[index name]. straight?
>
> eg
> hibernate.search.[index name].use_compound_file
>
this is not how it is working now, you still need to use either
.transaction or .batch.
Also you should use .indexwriter.transaction as omitting the
".indexwriter" is deprecated.
So I would agree with
hibernate.search.[index name].transaction
but this is not currently supported.
Also the current cfg parsing is expecting a tree of options, depth
having proprity, because of all
different configuration rules:
1- batch inheriting from transaction
2- use or not to use .indexwriter (backwards compatibility)
3- inheritance from .default
4- sharded nested configurations... defaulting to upper node.
maybe I forgot some more cases.
Therefore it would be more complex (currently) to NOT accept a
parameter under "transaction" or "batch"
but give priority for the root node for some cases; not so complex to
ALSO accept a parameter under .indexwriter
only (without the transaction or batch part).
Sanne