[hibernate-dev] use_compound_file

[Emmanuel Bernard]

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 at 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 at 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