Re: [infinispan-dev] Why is loading from store needed before storing in cache store?

2010/10/20 Manik Surtani <manik(a)jboss.org&gt;: > On 20 Oct 2010, at 09:58, Sanne Grinovero wrote: > >> 2010/10/20 Manik Surtani <manik(a)jboss.org&gt;: >>> On 15 Oct 2010, at 01:05, Sanne Grinovero wrote: >>> >>>> I'd vote for A), as I would be happy enough having just SKIP_CACHE_LOAD. >>>> having a UNRELIABLE_RETURN_VALUES might seem a handy shortcut, but is >>>> not needed as long as I can use both SKIP_REMOTE_LOOKUP and >>>> SKIP_CACHE_LOAD, it's important that the user can tune as he wants. >>>> (So I'm fine with C too, just there's a flag which isn't really needed) >>>> >>>> Also I'm puzzled with the idea to have overloaded methods which return >>>> void, I have to admit I had it wrong once after a "quick change" for >>>> which the return value became important but I had forgot to remove the >>>> flags :) >>> Fair enough, but my real issue here is to prevent a public API/interface that is too complex to use. Since we do want to extend Map, methods should be map-like and hence simple. >>> >>> Are you suggesting something like: >>> >>> cache.put2(K, V) which returns void, and perhaps internally calls cache.withFlags(SKIP_CACHE_LOAD, SKIP_REMOTE_LOOKUP).put(K, V)? >> Yes I'd suggest something like that, but only if we can come up with a >> good name to not pollute the API with too many methods. >> This should be applied to all methods returning something, maybe we >> can have something like getAdvancedCache(), a method >> getNoreturnValuesCache() which returns a super interface having all >> new methods too? (to hide them in the simple Cache). > I don't mind adding such syntactic sugar if we can think of a clean way (API-wise) to do this. what about something similar to .withFlags(...) API suggested by Emmanuel: cache.ignoringReturnValues().remove(); cache.ignoringReturnValues().put("key","value"); implementations would just enable all needed flags, and delegate to existing one. of course I'm using an interface which will *not* extend neither Cache nor Map, or this would defeat the purpose. cache.ignoringReturnValues().putAsync("today", "20 October 2010", 2, TimeUnit.HOURS); In this case the implementation could avoid the creation of the Future (afaik that's not possible right now?) better names? cache.asVoid().remove(); cache.disableFetch().remove(); cache.thisIsToDisableReturnValuesAndMakeSureYouWonTUseItAndYesTheAPIAuthorWasHackingInAPubInCaseYouWondered().remove();