On 12 Jun 2013, at 13:14, Galder Zamarreño <galder(a)redhat.com> wrote:
On Jun 10, 2013, at 12:01 PM, Adrian Nistor <anistor(a)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)