sorry I didn't understand what the purpose is, I just wanted to warn that Search needs to read all keys, and doesn't know the exact names beforehand. Consolidating the constants in a single place looks like a good thing, just wanted to check you aren't going to hide the other properties for now. I missed the reason of why the discussion switched from consolidating constants to changing the properties management.
cheers, Sanne 2010/2/3 Steve Ebersole <st...@hibernate.org>: > First, this is not the option I suggest for now. It's pretty invasive > change > > Well exposing the full set of properties sort of defeats the entire > purpose no? > > > On Wed, 2010-02-03 at 14:42 +0100, Sanne Grinovero wrote: >> Hi Steve, >> please expose in some way the fullPropertySet too, as Search needs to >> be able to get a list of all defined keys, for example it reads >> options like >> >> hibernate .search.Animals.batch.merge_factor = 20 >> or >> hibernate .search.Animals.5.batch.merge_factor = 30 >> >> Where Animals is the name of an index, and the 5 stands for an option >> to override the fifth index shard. >> >> Also keep in mind I know of some users on the forum who added "own" >> properties to configure their custom extensions, so it would be a good >> idea to be able to read all kind of properties at runtime. >> Additionally the Infinispan team is asking for "dynamic" configuration >> capabilities in Search, so it's possible that some option will need to >> be read lazily, i.e. not at framework startup but in a later >> timeframe, for example when we first see an event about a new - >> previously unmapped - entity. >> >> Did you consider "key scoping" of the Properties, something like >> Search already does to parse the above structure as a tree? >> In short it hides all properties not having a key which begins with a >> specified prefix, it is recursive and extends Properties: >> http://fisheye.jboss.org/browse/Hibernate/search/trunk/src/main/java/org/hibernate/search/backend/configuration/MaskedProperty.java?r=17630 >> >> Sanne >> >> >> 2010/2/3 Steve Ebersole <st...@hibernate.org>: >> > Here is the basic idea: http://pastebin.com/m6add9d4b >> > >> > Rather than passing around Properties, we'd pass somethign like that >> > around. Then we'd use its "getConsumedProperties". >> > >> > >> > On Wed, 2010-02-03 at 10:05 +0100, Emmanuel Bernard wrote: >> >> That's the point Hardy, the list of consumed properties is not known in >> >> advance in Hibernate search. Or is the plan get core pass all the raw >> >> Properties and HSearch return the list of properties it really wants? In >> >> which case it will return all of them to implement our current approach. >> >> >> >> I guess the point is that I am lost and don't see how (my understanding >> >> of) the pull second option can work for Search. >> >> >> >> On 2 févr. 2010, at 15:12, Hardy Ferentschik wrote: >> >> >> >> > For the Hibernate Search case I could imagine to implement Steve's >> >> > second pull >> >> > approach. Search already defines an interface SearchConfiguration which >> >> > delegates the >> >> > access to the underlying Configuration properties. It should be easy to >> >> > implement some >> >> > sort of journaling to keep track which properties Search consumes. >> >> > >> >> > If we can keep track of the consumes properties we should be able to >> >> > report this back >> >> > into Core via the PropertyConsumer#collectConsumedProperties approach. >> >> > >> >> > WDYT? >> >> > >> >> > --Hardy >> >> > >> >> > On Tue, 02 Feb 2010 09:54:57 -0300, Steve Ebersole >> >> > <st...@hibernate.org> wrote: >> >> > >> >> >> The 'know in advance' approach is exactly what I was trying to avoid. >> >> >> I guess that is another option I forgot on that list >> >> >> >> >> >> It's not the I want to implement (way too tedious). >> >> >> >> >> >> -- Sent from my Palm Pre >> >> >> st...@hibernate.org >> >> >> http://hibernate.orgEmmanuel Bernard wrote: >> >> >> >> >> >> Yep. >> >> >> >> >> >> Provided HSearch does not know in advance what properties are required >> >> >> by its plugins, I was wondering how that would work. That's why I >> >> >> asked Hardy for an implementation example as he seemed to have >> >> >> understood. >> >> >> >> >> >> >> >> >> >> >> >> On 1 févr. 2010, at 20:52, Steve Ebersole wrote: >> >> >> >> >> >> >> >> >> >> >> >>> For Search afaict as you mentioned listeners will be the touchpoint >> >> >> >> >> >>> here. So it depends on what is accessible to the listeners. >> >> >> >> >> >>> >> >> >> >> >> >>> At some point this just needs to be a best effort. >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> On Mon, 2010-02-01 at 18:42 +0100, Emmanuel Bernard wrote: >> >> >> >> >> >>>> Hardy, >> >> >> >> >> >>>> How would it work for say a DirectoryProvider in Hibernate search >> >> >>>> (which is a plugin of HSearch which itself is a plugin of Core in a >> >> >>>> way - listener). >> >> >> >> >> >>>> >> >> >> >> >> >>>> Remember we have the hibernate.search.default.[customproperty] >> >> >>>> category and the hibernate.search.[indexname].[customproperty] >> >> >>>> category. What would the the impl of >> >> >>>> PropertyConsumer#collectConsumedProperties like for Hibernate Search? >> >> >> >> >> >>>> >> >> >> >> >> >>>> >> >> >> >> >> >>>> On 1 févr. 2010, at 16:28, Hardy Ferentschik wrote: >> >> >> >> >> >>>> >> >> >> >> >> >>>>> The pull approach via an additional PropertyConsumer interface >> >> >>>>> works for me. >> >> >> >> >> >>>>> It seems to be a good trade-off. Least invasive while still getting >> >> >>>>> some order >> >> >> >> >> >>>>> into the properties. >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> --Hardy >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> On Mon, 01 Feb 2010 12:14:02 -0300, Steve Ebersole >> >> >>>>> <st...@hibernate.org> wrote: >> >> >> >> >> >>>>> >> >> >> >> >> >>>>>> On Mon, 2010-02-01 at 09:49 +0100, Emmanuel Bernard wrote: >> >> >> >> >> >>>>>>> Also "plugins" can make use of the general availability of >> >> >>>>>>> properties. >> >> >> >> >> >>>>>>> For example Hibernate Search reads everything under >> >> >>>>>>> hibernate.search (and it's not a limited set of property names). >> >> >>>>>>> Likewise, HSearch extensions can use whatever property name they >> >> >>>>>>> want to configure say the custom backend or the directory >> >> >>>>>>> providers (either custom or even one of the system properties). >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> The main use case I was keeping in mind along the way was caching. >> >> >>>>>> I know in the JBC and Infinispan integrations they added the >> >> >>>>>> ability to read a lot of config information from our properties. >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> As long as it is something configured by the Configuration -> >> >> >> >> >> >>>>>> Settings/SessionFactory process or the something is known to >> >> >> >> >> >>>>>> SessionFactory at the end of its init it is workable. For >> >> >>>>>> example, I >> >> >> >> >> >>>>>> imagine Validator would be easy to tie in here because of the >> >> >>>>>> listeners; >> >> >> >> >> >>>>>> they are known to the SessionFactory. Not so sure about Search, it >> >> >> >> >> >>>>>> registers listeners too so maybe its ok. >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> The first question is whether we want a push or pull (from >> >> >>>>>> perspective >> >> >> >> >> >>>>>> of the things being configured) model here. For example, would the >> >> >> >> >> >>>>>> ConnectionProvider tell SessionFactory about the properties it >> >> >>>>>> consumed >> >> >> >> >> >>>>>> (push)? Or would the SessionFactory ask the ConnectionProvider >> >> >>>>>> for that >> >> >> >> >> >>>>>> info (pull)? >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> The pull approach has the advantage of being the least trade-off . >> >> >>>>>> We >> >> >> >> >> >>>>>> could add an optional interface "PropertyConsumer" that things can >> >> >> >> >> >>>>>> choose to implement. If they do, the method would be something >> >> >>>>>> like >> >> >> >> >> >>>>>> "collectConsumedProperties(Map copy)"; they would put all the >> >> >>>>>> property >> >> >> >> >> >>>>>> keys/values into the given map. >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> Another potential "pull" approach is to not pass around >> >> >>>>>> j.u.Properties >> >> >> >> >> >>>>>> into these things to configure themselves, but to instead wrap >> >> >>>>>> that in a >> >> >> >> >> >>>>>> class that journals the key/values as they are requested. That is >> >> >>>>>> a bit >> >> >> >> >> >>>>>> more invasive though as it would mean changing quite a few >> >> >>>>>> contracts, >> >> >> >> >> >>>>>> some of which are implemented by classes outside our control. >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> In the "push" strategy, the things configuring themselves somehow >> >> >>>>>> push >> >> >> >> >> >>>>>> which properties (key/value) they are consuming. Much like the >> >> >>>>>> second >> >> >> >> >> >>>>>> pull-approach, this is pretty invasive because we would need to >> >> >>>>>> pass in >> >> >> >> >> >>>>>> the mechanism for these "configurables" to report back which >> >> >>>>>> properties >> >> >> >> >> >>>>>> they are consuming. Not to mention its tedious. >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> Long term I like the second pull approach. However, I personally >> >> >>>>>> think >> >> >> >> >> >>>>>> it is too disruptive in the short term and that we should use the >> >> >>>>>> first >> >> >> >> >> >>>>>> pull approach for now. >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> Thoughts? >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>> >> >> >> >> >> >>>> >> >> >> >> >> >>> -- >> >> >> >> >> >>> Steve Ebersole <st...@hibernate.org> >> >> >> >> >> >>> Hibernate.org >> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> > -- >> > Steve Ebersole <st...@hibernate.org> >> > Hibernate.org >> > >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > -- > Steve Ebersole <st...@hibernate.org> > Hibernate.org > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
