>> 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 > >
