On 11 October 2011 15:43, Hardy Ferentschik <ha...@hibernate.org> wrote: > Hi, > > great, seems we are sharing the same view then. > I will go ahead change the Architecture and Configuration chapters > accordingly. > It won't be in the release tomorrow, but definitely for the Final. > > >>> * 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." > > ok. Are we consistent with this though? I am not sure we are, but I will > double > check. But basically that was just a typo.
Yes we are consistent with this. In fact IndexManager implementations only receive the properties from under these paths so anything inconsistent wouldn't be able to work. > >> 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 > > Didn't we have the discussion once before? We do it this way, because its > what we do in Core? But I think even there we have some org.hibernate.xyz > and some hibernate.xyz > > I have no strong opinion on transparently allowing the 'org' prefix. Ok, just wondering as this is definitely not the most urgent change; I'll open an issue, seems a good starting point for a new contributor. HSEARCH-942 >> 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 > > No it is not and I am not so happy about the 'default' value either. > As you say, it gets too confusing. Question is what to about it? > Deprecating the default values? Or even removing them. > >> We have an issue open around reviewing configuration properties, this >> thought was one of the reason to open it: >> >> HSEARCH-859 - Review names and composition of configuration properties > > I know. I mentioned it to Emmanuel today. It would have been better to > address > this issue for the 4.0 release, but given the time constraints we skipped > it. WDYM ? 4.0 was not released yet, if we see a change which should be done, we should be able to make them now. > This means these changes need to be deferred until 4.1 where we then, > unfortunately, > also have to care about backward computability. Unfortunate, really. > >> Sounds all good. I'm not touching docs myself to avoid conflicts, but >> if you want to assign me some tasks in isolated chapters. > > Changing anything outside chapter 2 and 3 is safe. I will focus on these > two > for now (and some minor typo fixes I have for the Getting Started section, > I'll > will create a separate pull request for them) > > --Hardy > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
