Hi Galder ! Thanks for your comments and ideas ! I'm going to move the content you posted in the list to the design PR here : https://github.com/infinispan/ infinispan-designs/pull/3
++ Katia On Thu, Apr 13, 2017 at 11:31 PM, Galder Zamarreño <gal...@redhat.com> wrote: > > -- > Galder Zamarreño > Infinispan, Red Hat > > > On 5 Apr 2017, at 10:05, Sebastian Laskawiec <slask...@redhat.com> > wrote: > > > > I love the idea of starting with a simple interface, so +1000 from me. > > > > I'm also assuming that our new MultiMap will be accessible in both > Embedded and Client/Server mode, am I correct? I also think CacheMultimap > should extend Iterable. I suspect some of our users might want to use > for-each loop with it. > > Hmmmm, that would only really work for a synchronous API version. For > async you'd something like Traversable that we did for the functional map > experiment. > > > Finally, we also need to think about some integration bits (maybe not > for the initial implementation but it might be beneficial to create JIRAs > for them). With CDI and Spring support we can make them super easy to use > (by injecting newly created instances to the users code: @Inject > CacheMultimap myMap<String, String>). > > > > I also put some more comments below. Nice proposal Katia! > > > > On Tue, Apr 4, 2017 at 7:09 PM William Burns <mudokon...@gmail.com> > wrote: > > On Tue, Apr 4, 2017 at 11:45 AM Katia Aresti <kare...@redhat.com> wrote: > > Hi all, > > > > As you probably know, Will and I are working on the vert-x infinispan > integration [1], where the primary goal is to make infinispan the default > cluster management of vert-x. (yeah!) > > Vert-x needs support for an Async Multimap. Today's implementation is a > wrapper on a normal Cache where only Cache Key's are used to implement the > multi map [2]. > > This is not very efficient, so after trying some other alternative > implementations [3] that don't fully work (injection not working), Will and > I have come to the conclusion that it might be a good idea to start having > our own native CacheMultimap. This first multimap won't support duplicate > values on key's. > > > > As a quick start, the smallest multimap we need should implement the > following interface : > > > > I agree that having a very slim API to start should be better since we > know how much trouble we get into implementing a very large API like > ConcurrentMap :) > > public interface CacheMultimap<K, V> { > > V put(K key, V value); > > This should probably return a boolean or Void. I am leaning towards the > first, but I am open either way. > > > > Could you please tell me more why are you suggesting boolean or void? > Returning previous value would make it more similar to a Map. > > > > Collection<V> get(K key); > > > > boolean remove(K key, V value); > > We probably want a `boolean remove(K key)` method as well that removes > all values mapped to the given key. > > > > +1 > > > > } > > CacheMultimapImpl will be a wrapper on a normal Cache, similar to [3]. > > > > We could add a new method in EmbeddedCacheManager.java > > > > <K, V> CacheMultimap<K, V> getCacheMultimap(String cacheName, boolean > createIfAbsent); > > > > How about the other way around? Something like: > > static <K, V> CacheMultimap<K, V> CacheMultimap.create(BasicCache<K,V> > cache); > > > > This way we would avoid dependency from DefaultCacheManager to > CacheMultimap. If we wanted to support both Embedded/Client Server mode we > would probably need to use BasicCache as a parameter. The last argument for > this solution is that creating producers in CDI/Spring would be trivial (we > would just need to provide a generic producer method and with some luck > that would be it). > > > > > > I was thinking maybe this would exist in a separate module (outside of > core)? or class that wraps (similar to DistributedExecutor) instead. My > worry is about transactions, since the entry point to that is through Cache > interface. The other option is we could add a `getCache` method on the > `CacheMultiMap`. > > > > If we want to support both Embedded/Client Server mode, it should go to > commons. Otherwise I would vote for core. > > > > > > > > > > Implementation will create a cache as always and return a new > CacheMultimapImpl(cache). > > > > What do you think ? Please fell free to suggest any other alternative or > idea. > > > > Cheers > > > > Katia > > > > [1] https://github.com/vert-x3/vertx-infinispan > > > > [2] https://github.com/vert-x3/vertx-infinispan/blob/master/ > src/main/java/io/vertx/ext/cluster/infinispan/impl/ > InfinispanAsyncMultiMap.java > > > > [3] https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > > SEBASTIAN ŁASKAWIEC > > INFINISPAN DEVELOPER > > Red Hat EMEA > > > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev