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

["이희승 (Trustin Lee)"]

Sanne Grinovero wrote:
> 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();

To avoid the overhead of setting frequently used flags, I'd suggest
these flag methods to return a decorated or duplicated Cache instance
with updated default flags.

Cache myCache;
myCache = cache.withFlags(SKIP_REMOTE_LOOKUP, SKIP_CACHE_LOAD, ...);
myCache.remove();

A user could even have multiple Cache instances that decorates the same
cache with different flags.

But wait, don't we already have a similar one in AdvancedCache?  It
seems stateful unlike my suggestion though.  If it can be stateless like
I suggested, I think it could be moved up to Cache.

-- 
Trustin Lee - http://gleamynode.net/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 290 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20101021/d6e0762b/attachment.bin