On 12 Jun 2013, at 13:14, Galder Zamarreño <gal...@redhat.com> wrote:

> 
> 
> On Jun 10, 2013, at 12:01 PM, Adrian Nistor <anis...@redhat.com> 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**.

this would be the elegant way of doing it.

> 
> 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
I've update the JIRA to track the fact that IGNORE_RETURN_VALUES + get should 
not be possible.

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)





_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Reply via email to