On Apr 8, 2013, at 11:17 AM, Manik Surtani <msurt...@redhat.com> wrote:
> All sounds very good. One important thing to consider is that the reference > to Metadata passed in by the client app will be tied to the ICE for the > entire lifespan of the ICE. You'll need to think about a defensive copy or > some other form of making the Metadata immutable (by the user application, at > least) the moment it is passed in. ^ Excellent point, it could be a nightmare if users could change the metadata reference by the ICE at will. I'll have a think on how to best achieve this. Cheers, > > On 8 Apr 2013, at 09:24, Galder Zamarreño <gal...@redhat.com> wrote: > >> Hi all, >> >> As mentioned in >> http://lists.jboss.org/pipermail/infinispan-dev/2013-March/012348.html, in >> paralell to the switch to Equivalent* collections, I was also working on >> being able to pass metadata into Infinispan caches. This is done to better >> support the ability to store custom metadata in Infinispan without the need >> of extra wrappers. So, the idea is that InternalCacheEntry instances will >> have a a reference to this Metadata. >> >> One of that metadata is version, which I've been using as test bed to see if >> clients could pass succesfully version information via metadata. As you >> already know, Hot Rod requires to store version information. Before, this >> was stored in a class called CacheValue alongside the value itself, but the >> work I've done in [1], this is passed via the new API I've added in [2]. >> >> So, I'd like to get some thoughts on this new API. I hope that with these >> new put/replace versions, we can get rid of the nightmare which is all the >> other put/replace calls taking lifespan and/or maxIdle information. In the >> end, I think there should be two basic puts: >> >> - put(K, V) >> - put(K, V, Metadata) >> >> And their equivalents. >> >> IMPORTANT NOTE 1: The implementation details are bound to change, because >> the entire Metadata needs to be stored in InternalCacheEntry, not just >> version, lifespan..etc. I'll further develop the implementation once I get >> into adding more metadata, i.e. when working on interoperability with REST. >> So, don't pay too much attention to the implementation itself, focus on the >> AdvancedCache API itself and let's refine that. >> >> IMPORTANT NOTE 2: The interoperability work in commit in [1] is WIP, so >> please let's avoid discussing it in this email thread. Once I have a more >> final version I'll send an email about it. >> >> Apart from working on enhancements to the API, I'm now carry on tackling the >> interoperability work with aim to have an initial version of the Embedded >> <-> Hot Rod interoperability as first step. Once that's in, it can be >> released to get early feedback while the rest of interoperability modes are >> developed. >> >> Cheers, >> >> [1] >> https://github.com/galderz/infinispan/commit/a35956fe291d2b2dc3b7fa7bf44d8965ffb1a54d >> [2] >> https://github.com/galderz/infinispan/commit/a35956fe291d2b2dc3b7fa7bf44d8965ffb1a54d#L10R313 >> -- >> Galder Zamarreño >> gal...@redhat.com >> twitter.com/galderz >> >> Project Lead, Escalante >> http://escalante.io >> >> Engineer, Infinispan >> http://infinispan.org >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > ma...@jboss.org > twitter.com/maniksurtani > > Platform Architect, JBoss Data Grid > http://red.ht/data-grid > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
