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

[Sanne Grinovero]

2010/10/20 Manik Surtani <manik at jboss.org>:
>
> On 20 Oct 2010, at 09:58, Sanne Grinovero wrote:
>
>> 2010/10/20 Manik Surtani <manik at jboss.org>:
>>>
>>> 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();

Cheers,
Sanne

<snip />