Currently it only sets the lastChanged timestamp on ANY change. https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/ConfigImpl.java#L239
This gets evaluated during the cache access: https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/TypedResolverImpl.java#L245 and for snapshots: https://github.com/apache/deltaspike/blob/master/deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/config/ConfigImpl.java#L133 LieGrue, strub > Am 05.06.2018 um 09:22 schrieb Jean-Louis MONTEIRO <[email protected]>: > >>> Some values may have been updated, some might have been deleted and some >>> other added. >>> Returning a set might not be enough, isn't it? > >> We really only need the property names which got changed: >> * new ones >> * deleted ones >> * the ones with different values >> >> So a Set<String> is fine. > > The thing is that you will get the key of everything that changed which > requires to invalidate the cache for all entries (lock?). > Or you would need to iterate all the keys, compare again old/new and delete > entries from cache, do nothing for add (? they will be lazily added during > lookup maybe) and invalidate the updated values. > > That seems to be heavy to handle for nothing has during compare we have all > information already. > > > > Le mar. 5 juin 2018 à 09:10, Mark Struberg <[email protected]> a > écrit : > >> Hi JL! >> >> Thanks for the feedback! >> And yes, this will also be important for ConfigJSR (and later mp-config as >> well). >> >> >>> First it's all about config, so maybe having a method name "diff" is >>> enough. No need for "diffConfig". >> >> Well, diff alone is imo a bit too short as it doesn't have any context >> about what to diff. >> Thus I'd prefer diffConfig. >> >> >>> Some values may have been updated, some might have been deleted and some >>> other added. >>> Returning a set might not be enough, isn't it? >> >> We really only need the property names which got changed: >> * new ones >> * deleted ones >> * the ones with different values >> >> So a Set<String> is fine. >> >> LieGrue, >> strub >> >> >>> Am 05.06.2018 um 08:59 schrieb Jean-Louis MONTEIRO <[email protected]>: >>> >>> Few thoughts ... >>> >>> I did not follow really deltaspike to be honest, but I do follow >> MP-Config >>> for instance. >>> >>> First it's all about config, so maybe having a method name "diff" is >>> enough. No need for "diffConfig". >>> >>> Some values may have been updated, some might have been deleted and some >>> other added. >>> Returning a set might not be enough, isn't it? >>> >>> Jean-Louis >>> >>> >>> >>> >>> >>> >>> Le mar. 5 juin 2018 à 08:55, Mark Struberg <[email protected]> a >>> écrit : >>> >>>> Hi folks! >>>> >>>> For the new DS-1.9 feature to 'push' config changes we need an algorithm >>>> to detect whether an old and a new config differs. >>>> >>>> The signature would be something like: >>>> >>>> /** >>>> * >>>> * A Set of all the attributes which differ between the old and new >> config >>>> Map. An empty Set if there is no difference. >>>> */ >>>> public Set<String> diffConfig(Map<String, String> oldValues, Map<String, >>>> String> newValues) >>>> >>>> This is intended for e.g. background threads which read from a database >>>> once per second and compare the old values with the new ones. >>>> If there was any difference then the set of attributes get reported back >>>> to the Config (which in turn clears the caches, etc). >>>> >>>> >>>> Now where to put this method? >>>> >>>> My candidate would be >>>> org.apache.deltaspike.core.api.config.ConfigResolver.ConfigProvider >>>> I do not want to put it into the Config interface itself because it is >> not >>>> a user contract thingy. >>>> And I also do not want to put it into ConfigResolver becasue I'd like to >>>> have the impl only available internally and not bloat the ConfigResolver >>>> any further. >>>> >>>> Wdyt? >>>> >>>> LieGrue, >>>> strub >> >>
