Re: [hibernate-dev] [hsearch] documentation
I see where you're coming from.
There are two options:
- don't care that much
- rename default to default_for_index or index_default (or some long and annoying name
like that) and deprecate default
Do you really think filter is in as much need as index for a default? Any other category
that would be in need for that?
On 11 oct. 2011, at 17:39, Sanne Grinovero wrote:
>
> I am against it. All the doc is consistent, I don't want two options to do one
thing if they are strictly equivalent.
Sure, I'm not suggesting to support it: as I've written in the
description of HSEARCH-942 such a property should log a warning: we
could warn only, but we could also warn and still apply the property.
I'm happy to warn only if you prefer.
>> on b) : I really think this ".default" business got out of hand; it
>> made sense in initial days as there wasn't much to configure, but
>> nowaday? Is it still self-speaking that "default" relates to the
>> IndexManager / indexes ?
>
> Can you be specific? default is a great way to apply the same behavior for all of
your indexes. Unless I've lost a train, using the same type of backend with the same
settings is likely to be the most probable choice for a lot of deployments.
There are properties which are not related to a specific IndexManager:
_hibernate.search.lucene_version_
_hibernate.search.filter.cache_docidresults.size_
and some which are:
_hibernate.search.default.directory_provider_
_hibernate.search.default.indexwriter.merge_factor_
I definitely like the default mechanics, what I'm pointing out is that
it's not clear that "default" is referring to the "default
index",
which is an abstract contept to make it harder.
If this was a method to specify a default value for any property, I
would expect it to work too for
_hibernate.search.default.filter.cache_docidresults.size_
(which doesn't work as it's a different category).