On Mar 13, 2014, at 12:45, William Burns <mudokon...@gmail.com> wrote:
> On Thu, Mar 13, 2014 at 8:37 AM, Pedro Ruivo <pe...@infinispan.org> wrote: >> >> >> On 03/13/2014 12:35 PM, William Burns wrote: >>> On Thu, Mar 13, 2014 at 8:31 AM, Pedro Ruivo <pe...@infinispan.org> wrote: >>>> Hi, >>>> >>>> #1 and #2 are ok to me but, IMO, the filter package should be in commons >>>> module >>> >>> Sorry I forgot to detail why I said core. I originally planned for >>> commons package as well, however the KeyValueFilter class needs the >>> Metadata class, which doesn't live in the commons package. I didn't >>> want to separate the 2 filter classes. And unfortunately the Metadata >>> class relies on other classes in core, so that isn't easy to move over >>> either, but doable :( WDYT? >> >> can you explain why the metadata is needed? I assumed that the key and >> the value were the only objects needed. > > That is how the design doc was written up :P My guess is so that > people if needed can filter out versioned entries or to possibly do > some eviction magic since they can try to calculate when the entry > would be removed. Maybe Mircea can shed some additional light. org.infinispan.metadata.Metadata was added in order to group all the information that needs to be associated with a cache entry: timestamp, expiry, idleTime, version but also custom external data that ISPN extension might want to associate with it: e.g. REST server associates MIME information: https://github.com/mmarkus/infinispan/blob/master/server/rest/src/main/scala/org/infinispan/rest/MimeMetadata.scala#L20-20. 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
