On Mar 13, 2014, at 12:45, William Burns <[email protected]> wrote:
> On Thu, Mar 13, 2014 at 8:37 AM, Pedro Ruivo <[email protected]> wrote: >> >> >> On 03/13/2014 12:35 PM, William Burns wrote: >>> On Thu, Mar 13, 2014 at 8:31 AM, Pedro Ruivo <[email protected]> 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 [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
