[infinispan-dev] FlagAffectedCommand interface hierarchy (ISPN-761)

[William Burns]

Yeah I was thinking of changing it to be the inverse as you were thinking.  There are a few places such as EntryFactory, CacheNotifier, and a few interceptors that reference the FlagAffectedCommand that will have to be changed around.  Hopefully these class definitions are fine to change as well, I don't believe they are usually referenced by external code.  I will look into it more later this week or next week though since this isn't going to make 5.3.

Thanks for the input guys.

----- Original Message -----
From: "Galder Zamarreño" <galder at redhat.com>
To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
Sent: Monday, June 3, 2013 9:24:46 AM
Subject: Re: [infinispan-dev] FlagAffectedCommand interface hierarchy	(ISPN-761)


On May 31, 2013, at 3:37 PM, William Burns <wburns at redhat.com> wrote:

> While adding changes for cache methods (entrySet, keySet, values, size) to include passivated entries it had been pointed out to conditionally do these operations if flags such as SKIP_CACHE_STORE and SKIP_CACHE_LOAD were provided.  Also does anyone have any feedback on if both flags should apply or just say SKIP_CACHE_STORE?  Currently SizeCommand, EntrySetCommand, ValuesCommand and KeySetCommand do not inherit from FlagAffectedCommand which are used for commands that behavior is dependent upon flags.
> 
> The problem is that FlagAffectedCommand currently extends VisitableCommand, TopologyAffectedCommand, MetadataAwareCommand interfaces.  These interfaces do not really apply to the commands I am working on as they are local only.  

^ This is a new scenario really. Normally all flagged operations where clustered. In fact, FlagAffectedCommand was added to ship flags around, which we didn't used to do at the beginning ;).

> I was planning on removing the extended interfaces from the FlagAffectedCommand interface and update all the commands that implement this interface currently to make sure they still properly implement the additional interfaces.  Searching for instanceof FlagAffectedCommand it also appears that all current references should be alright after refactoring.  Once these interfaces are decoupled I can add the FlagAffectedCommand interface to the SizeCommand, EntrySetCommand, ValuesCommand and KeySetCommand and subsequently to the CommandFactory and my changes should be good.
> 
> Any opinions or concerns?

Hmmm, since now all commands (local or clustered) can carry flags, what about making VisitableCommand extend FlagAffectedCommand? That might be easier way to solve this issue...

> 
> Thanks,
> 
> - Will
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz

Project Lead, Escalante
http://escalante.io

Engineer, Infinispan
http://infinispan.org


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