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" <[email protected]>
To: "infinispan -Dev List" <[email protected]>
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 <[email protected]> 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
> [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

_______________________________________________
infinispan-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Reply via email to