well why I want to step back is just cause we slowly leave config
field and we are implementing a storage solution. There are already
numerous projects doing it at apache - even if they can sometimes
mandate some infra - so we should stick to the first goal of tamaya.
I also not fully agree with the basis - in particular the SPI to be
clear - we have ATM.
To sumamrize a first release with:
1) SPI ("provider" + property source)
2) basic merge/conflict policy
3) String read API
4) basic convertion support
Is far enough IMO.
Once all of it is clear I'd like we do a release to gather feedback
then continue building on top of it - we are ATM in the tunnel ;).
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2015-01-22 13:47 GMT+01:00 Tresch, Anatole <[email protected]>:
> Hi Romain/all
>
> I think we have quite a common agreement on the basic functions designed so
> far and I do not want to
> reinvent or change any of the basic mechanism. I simply come up with a simple
> request to use the algorithm pattern
> for a small subset of a functionality (how the final property value is
> evaluated). The usage of TypeLiteral was even your
> own proposal AFAIK, when we discussed PropertyConverters ;) ).
>
> Our current configuration model in general IMO is a very good start. It is
> already so flexible that I can implement 60-70% of use cases
> I have currently in use within Credit Suisse (this is somehow my "benchmark",
> which from my discussions I had during the last years covers a
> majority of use cases when dealing with distributed and modular systems).
>
> I am sure you remember, we had a discussion on another mail thread yesterday
> about Collection support. My proposal
> basically is the outcome of having played around to extend our API to support
> collections based only on Map<String,String>
> only as internal PropertySource representation thus avoiding the String[]
> getListProperty(String) methods.
>
> So for getting type information and define the content type of collections we
> need TypeLiterals, which similarly is useful perhaps for other non collection
> cases. Since collection entries can be defined in different property
> sources, a final list may want to contain all the properties found, instead
> of overriding,
> so values of different property sources are to be combined. AFAIK you
> already agreed on that UC. Hardcoding yet another strategy IMO makes
> no sense, so I would recommend use the default for all common aspects (that
> is what we already have in place) and add support for adapting the default
> where it is not appropriate. Thinking on this IMO both aspects (TypeLiterals
> and the collector) are the same for evaluating single property values as well,
> so regarding that it makes no sense to model collections differently, but
> extend/flexibilize the way how we can access properties in general.
>
> I tried to combine both aspects in one class, which I called PropertyQuery.
> Perhaps also the name PropertyQuery is confusing. Alternates would be
> PropertyRequest, PropertyAccess,... or whatever you like, I am completely
> open here ;)
>
> We can postpone that discussion, but just stopping this discussion now will
> not solve anything. Also we already invested a lot of discussing collection
> support, why stop here.
> We have enough time I think. We have important use cases to solve that may
> affect the Configuration interface as a whole. Adding them later may be a bad
> idea, so we
> should sort out these things now IMO.
>
> So I am curious to see your concrete (improvement) proposals ;), so we can
> continue to see, if we end up in a common view. If so, others on the mailing
> list also have a
> chance to join us again, I think.
>
> Anatole
>
>
> -----Original Message-----
> From: Romain Manni-Bucau [mailto:[email protected]]
> Sent: Donnerstag, 22. Januar 2015 09:45
> To: [email protected]
> Subject: Re: PropertyQuery
>
> not exactly, it is different to expose MapReduce in API and to
> implement it behind another concept, ATM it is an implementation
> detail.
>
> Why I worry a bit about Query stuff is we start to leave configuration
> layer to enter backend one, not sure it does worth it *to start* - I
> understand your feature even if I never needed it but I'd really like
> we ensure our basis are solid enough before adding features on top of
> them.
>
> Said otherwise I think we should now focus on trying to make a 0.1 -
> we can add alpha to make obvious we are not done - and stop adding
> anything before being fully agree on all we have.
>
> Does it make sense?
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-22 9:39 GMT+01:00 Anatole Tresch <[email protected]>:
>> Hi Romain
>>
>> About lamba friendly I can still have a Builder that creates a query. Works
>> perfectly.
>> The default use cases would remain as is. Queries would just add about 3
>> methods to Configuration. We get as well all the flexibility we would need
>> for collection support as well ;)
>>
>> Mapreduce? Well what else is evaluating a chain of propsources by
>> overridding? Its already there, but hardcoded the same, which is obviously
>> not flexible enough!
>>
>> -
>> Anatole Tresch
>> Glärnischweg 10
>> 8620 Wetzikon
>> Tel +41 (43) 317 05 30
>> -
>> Send from Mobile
>>
>>> Am 22.01.2015 um 09:11 schrieb Romain Manni-Bucau <[email protected]>:
>>>
>>> isnt it too complicated for most common use cases (+ not that lambda
>>> friendly cause of the 4 parameters which dont help writing readable
>>> code IMO).
>>>
>>> Functionally it works but it makes default cases "hard" and actually
>>> you just want to implement the MapReduce pattern so maybe we should
>>> call it this way if we go this way.
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau
>>> http://www.tomitribe.com
>>> http://rmannibucau.wordpress.com
>>> https://github.com/rmannibucau
>>>
>>>
>>> 2015-01-22 8:44 GMT+01:00 Anatole Tresch <[email protected]>:
>>>> Dear all
>>>>
>>>> *let's think about additional use cases:*
>>>> 1) as mentioned in my last mail about collection types,* overriding may not
>>>> always be the right resolution policy *for accessing a configured value
>>>> (e.g. for collecting all configured values in a final set/list).
>>>> 2) sometimes I want to define my own PropertyConverters (already
>>>> implemented)
>>>> 3) sometimes I even would like to evaluate multiple keys taking the result
>>>> of the first property key that returns a config property (nice convenience)
>>>>
>>>> When we will add all this kind of aspect into Configuration, we will end up
>>>> in a messy interface, e.g. for
>>>> String get(String);
>>>> <T> T get(String, Class<T>);
>>>> <T> T get(String, Class<T>, PropertyConverter);
>>>>
>>>> String get(String, ValueCollector);
>>>> <T> T get(String, Class<T>, ValueCollector);
>>>> <T> T get(String, Class<T>, PropertyConverter, ValueCollector);
>>>> ...
>>>>
>>>> Obviously that does not make sense.
>>>>
>>>> Instead of I would propose, we would define a PropertyQuery, which
>>>> basically is
>>>>
>>>> - is the same as a TypeLiteral<T> solving the type aspects
>>>> - has a list of *keys* to be evaluated, at least one
>>>> - optionally has a ValueCollector
>>>> - optionally has a list of PropertyConverter
>>>>
>>>> With that our interface gets much leaner, but still flexible enough to
>>>> accommodate the use cases above:
>>>>
>>>> String get(String);
>>>> <T> T get(String, Class<T>);
>>>> <T> T get(String, Class<T>, PropertyConverter); // may be ommitted as well
>>>> ?
>>>> <T> get(PropertyQuery<T> query);
>>>> ...
>>>>
>>>> This solves all use cases above and gives us an easy way to add additional
>>>> feature, if needed (I dont see any, but who knows). Hereby ValueCollector
>>>> would be defined as follows:
>>>>
>>>> @FunctionalInterface
>>>> public interface ValueCollector {
>>>>
>>>> /**
>>>> * Method that is called for each value returned by a PropertySource
>>>> for the given key.
>>>> * @param currentValue the current value, including null.
>>>> * The collector should either combine the existing
>>>> value with value from {@code currentValue}
>>>> * or replace the value in {@code currentValue}
>>>> with {@code valueRead}, hereby returning the
>>>> * result to be used as new {@code currentValue}.
>>>> * @param key The current key to be evaluated.
>>>> * @param newValue the new value read from the current {@code
>>>> propertySource}, not null.
>>>> * @param propertySource The PropertySource that returned the current
>>>> value (either as the result of a direct
>>>> * access of as a property Map containing the
>>>> given key. The PropertySource given
>>>> * may be evaluated for additional meta-data, how
>>>> the given values are to be combined.
>>>> * @return the value to be used for future evaluation.
>>>> */
>>>> String collect(String key, String newValue, PropertySource
>>>> propertySource,
>>>> String currentValue);
>>>>
>>>> /**
>>>> * Default overriding collector.
>>>> */
>>>> public final ValueCollector DEFAULT_OVERRIDING_COLLECTOR = (k, nv, ps,
>>>> cv) -> nv;
>>>> }
>>>>
>>>> Feedback?
>>>>
>>>> Cheers,
>>>> Anatole
