I generally agree with the direction described by Hardy. Some comments inline
>> * the index manager gives access to directory and reader provider as well >> as the backend to be used > > This is a tricky point. Generally this is correct, especially for the > default IndexManager, but alternative implementations don't have to > use a backend, or at least not one as defined by > BackendQueueProcessor: we don't expose this interface so if someone > wants to implement an IndexManager using a different approach, they > can. And we will be providing some in 4.1+. We can call them Directory based IndexManagers which is the only family we have at the moment. As Sanne pointed out, other families will come in 4.2 or above. > >> * when using properties of the form org.hibernate.search.<index-name>.xyz >> you are effectively configuring the >> IndexManager for the specified index > > +1 > >> * properties of the form org.hibernate.search.xyz are default values which >> apply for any index manager if >> not overridden explicitly > > warning it's actually > "hibernate.search.default." > > a- no "org." in the front > b- it must end with ".default" to be picked up by other IndexManagers > > on a) : shall we relax this and allow "org." prefix too? This bytes > myself periodically I am against it. All the doc is consistent, I don't want two options to do one thing if they are strictly equivalent. > 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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
