On Jun 4, 2013, at 2:55 PM, Dan Berindei <dan.berindei(a)gmail.com> wrote:
On Tue, Jun 4, 2013 at 12:27 PM, Mircea Markus <mmarkus(a)redhat.com> wrote:
On 3 Jun 2013, at 19:01, Dan Berindei <dan.berindei(a)gmail.com> wrote:
> Fair point... ok, let's leave it as it is now.
>
>
> On Mon, Jun 3, 2013 at 5:23 PM, Galder Zamarreño <galder(a)redhat.com> wrote:
>
>
> On Jun 3, 2013, at 11:52 AM, Dan Berindei <dan.berindei(a)gmail.com> wrote:
>
>> Hi guys
>>
>> 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 :)
The flag business does need a big re-think. Not only to separate internal from external
flags (we have a jira for that), 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.
Cheers,
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org