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).