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
