[hibernate-dev] EMF / EM properties
Steve Ebersole
steve at hibernate.org
Wed Feb 3 12:26:59 EST 2010
I specifically said I did not want to "consolidate the constants in a
single place". Not in terms of this anyway. Because we will not know
them all ahead of time. Again, I don't see the difference between what
you mention and what would be needed for caching.
Emmanuel was asking specifically about the specific "second pull
approach", which is the context of my answer. There, given the way
y'all decided to form these property names, the only real option is to
process all properties starting with "hibernate.search" since that's the
most common base.
For caching (and search would fit here), I'd expect something like:
interface PropertyConsumer {
public boolean consumes(String name);
public void consume(String name, Object value);
}
class ConfigPropertySet {
...
void consumeProperties(PropertyConsumer consumer) {
Iterator itr = fullPropertySet.entries().iterator();
while ( itr.hasNext() ) {
Map.Entry entry = (Map.Entry) itr.next();
final String name = entry.getKey();
if ( consumer.consumes( name ) ) {
register( name, entry.getValue() ):
consumer.consume( name, entry.getValue() );
}
}
}
}
Or maybe even just:
interface PropertyConsumer {
public boolean consume(String name, Object value);
}
class ConfigPropertySet {
...
void consumeProperties(PropertyConsumer consumer) {
Iterator itr = fullPropertySet.entries().iterator();
while ( itr.hasNext() ) {
Map.Entry entry = (Map.Entry) itr.next();
final String name = entry.getKey();
if ( consumer.consume( name, entry.getValue() ) ) {
register( name, entry.getValue() ):
}
}
}
}
On Wed, 2010-02-03 at 17:19 +0100, Sanne Grinovero wrote:
> 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 <steve at 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 <steve at 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 <steve at 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
> >> >> >> steve at 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 <steve at 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 <steve at hibernate.org>
> >> >> >>
> >> >> >>> Hibernate.org
> >> >> >>
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> > --
> >> > Steve Ebersole <steve at hibernate.org>
> >> > Hibernate.org
> >> >
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > --
> > Steve Ebersole <steve at hibernate.org>
> > Hibernate.org
> >
> >
--
Steve Ebersole <steve at hibernate.org>
Hibernate.org
More information about the hibernate-dev
mailing list