On Jun 10, 2013, at 12:01 PM, Adrian Nistor <[email protected]> wrote:
> Maybe we could just clarify the javadoc of IGNORE_RETURN_VALUES and say that > it only applies to write operations and is ignored for everything else? Why > punish the user with an exception when doing a 'get'? > > We already document there's a (very common-sense) exception for conditional > writes were the flag is ignored (ISPN-3141). I wonder if anyone noticed my reply earlier... "The flag business does need a big re-think. Not only to separate internal from external flags (we have a jira for that [1]), but also to have a way to define which flags can be passed to a particular operation, in a way that's type-safe, and without resulting in a runtime error of the likes of "X flag cannot be used with Y operation". IOW, any error on which flag can be used with what operation should ideally be caught at compilation time. I don't have specific ideas on this right now, but I think it'd be good to achieve this." IOW, I suggest we leave it as it is. We need to re-think it anyway. So let's tackle it in 6.0 so that a get operation can never be passed IGNORE_RETURN_VALUES flag, and this being something that's caught at **compilation time**. I'm just about to add another internal flag to Flag as a result of the JCache 0.7 upgrade…, so need to tackle ISPN-2201 to avoid causing more confusion, and alongside avoid the issues that have been highlighted WRT which operations are allowed which flags. I'm happy to do this for 6.0. [1] https://issues.jboss.org/browse/ISPN-2201 > > On 06/10/2013 12:33 PM, Dan Berindei wrote: >> >> >> >> On Thu, Jun 6, 2013 at 9:08 PM, Ray Tsang <[email protected]> wrote: >> On Jun 6, 2013, at 13:26, Mircea Markus <[email protected]> wrote: >> >> > >> > On 4 Jun 2013, at 13:55, Dan Berindei <[email protected]> wrote: >> > >> >>>> CacheLoaderInterceptor and DistributionInterceptor both honour the >> >>>> IGNORE_RETURN_VALUES flag for get commands, but I think it would be >> >>>> more useful if they ignored it - just like they ignore it for >> >>>> conditional commands. >> >>>> >> >>>> That would make it possible for users to only keep a reference to a >> >>>> cache.getAdvancedCache().withFlags(IGNORE_RETURN_VALUES) and use it for >> >>>> both read and write operations. >> >>>> >> >>>> What do you think? >> >>> >> >>> If I was to take the role of a colleague of the person who's written the >> >>> Infinispan code, it'd be very confused to see a cache reference created >> >>> with IGNORE_RETURN_VALUES being used for a get() operation… I can see >> >>> myself thinking: "Why on earth do you call get with >> >>> IGNORE_RETURN_VALUES?" >> >> >> >> Isn't Galder's point not to allow invoking get with IGNORE_RETURN_VALUES? >> >> As both of you pointed out, Get + IGNORE_RETURN_VALUES doesn't make any >> >> sense :-) >> >> >> >> >> >> You'd think conditional operations with IGNORE_RETURN_VALUES don't make >> >> sense either, yet we have a special case to handle those as if the flag >> >> wasn't present :) >> > >> > I guess you're referring to ISPN-3141? >> >> Exactly. Does it make sense to call >> cache.withFlags(IGNORE_RETURN_VALUES).putIfAbsent(k, v)? What should it >> return? >> >> >> > Still I think Get + IGNORE_RETURN_VALUES doesn't make any sense :-) >> >> +1. It definitely threw me off... >> >> >> Ok, maybe IGNORE_RETURN_VALUES wouldn't be the best flag name for what I had >> in mind... I was thinking of a scenario where the application needs to do >> both reads and writes, but for writes it never needs to know the previous >> value. In that scenario it would make sense to call something like >> >> cache = >> cacheManager.getCache().getAdvancedCache().withFlags(IGNORE_RETURN_VALUES_ON_WRITES) >> >> at the beginning and only ever use that reference in the application. I >> agree that using the existing IGNORE_RETURN_VALUES flag for that would be a >> bit misleading, though. >> >> Should we change anything about the IGNORE_RETURN_VALUES, then? I guess it >> would be relatively simple to make it so that get() operations with the flag >> throw an exception and (optionally) put() operations always return null. >> Should I create an issue in JIRA for that? >> >> Cheers >> Dan >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño [email protected] twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
