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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
