-
Enhancement
-
Resolution: Obsolete
-
Major
-
None
-
None
-
None
-
None
List of enhancements that didn't make it into 8.0:
- Transaction support.
- Verify locks are acquired for all operations (once tx is in place, locks can be checked easily)
- Complete persistence support (remove many returning previous, put many returning previous, remove many)
- Replication of per-invocation parameters.
- Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs.
- Test interoperability with cache, e.g. cache put with lifespan can be retrieved via functional map with lifespan, and viceversa
- Test compatibility mode
- Add more listener events: activation, passivation and expiration.
- Use check isLocal instead of `e == null` in command impls
- Fix branch skip issue (see previous PR: https://github.com/infinispan/infinispan/pull/3571)
- Add externalizers for primitive versions of Optional.
- ValueMatcherMode indexes in MarshallableFunctionExternalizers should be based on ordinal() calls to annotation. Also, could the core's enumeration use the annotations defined in commons?
- Add AdvancedExternalizer version for functions that takes value matcher
- Complete support for MetaCreated and MetaLastUsed (which should be separated into MetaLastModified and MetaLastAccessed)
[ISPN-5704] Enhancements for Functional Map API
Galder Zamarreño
added a comment - Use case: we want to add an element to a List and the list is stored as V in the functional map. You could try using this function:
<R> CompletableFuture<R> eval(K key, V value, BiFunction<V, ReadWriteEntryView<K, V>, R> f)
But the problem is that the element to add to the list can't be passed in value since V is List and not the individual element. Could we have a more flexible value type? Could we have this?
<R, T> CompletableFuture<R> eval(K key, T value, BiFunction<T, ReadWriteEntryView<K, V>, R> f)
The problem then would be that we could not call view.set(value)... It needs some thought.
Galder Zamarreño
added a comment - Use case: we want to add an element to a List and the list is stored as V in the functional map. You could try using this function:
<R> CompletableFuture<R> eval(K key, V value, BiFunction<V, ReadWriteEntryView<K, V>, R> f)
But the problem is that the element to add to the list can't be passed in value since V is List and not the individual element. Could we have a more flexible value type? Could we have this?
<R, T> CompletableFuture<R> eval(K key, T value, BiFunction<T, ReadWriteEntryView<K, V>, R> f)
The problem then would be that we could not call view.set(value) ... It needs some thought. Galder Zamarreño
added a comment - Shall we provide order guarantees for Traversable returned from multi-key (evalMany methods) operations? Right now it's not guaranteed but it's implied.
Galder Zamarreño
added a comment - Shall we provide order guarantees for Traversable returned from multi-key (evalMany methods) operations? Right now it's not guaranteed but it's implied. evalMany methods taking Map should be typed more generically because the way entries has been defined, it can only carry value information but no metadata paramaters. In other words, with entries value side being ? extends V, it's difficult to construct to a Map where you have both value and metadata information, and then apply that. Here's how it looks now in WriteOnlyMap:
CompletableFuture<Void> evalMany(Map<? extends K, ? extends V> entries, BiConsumer<V, WriteEntryView<V>> f);
Here's how it could look:
<T> CompletableFuture<Void> evalMany(Map<? extends K, T> entries, BiConsumer<T, WriteEntryView<V>> f);
By doing that, T could be flexible enough to contain both value and any extra metadata parameters.
Galder Zamarreño
added a comment - - edited evalMany methods taking Map should be typed more generically because the way entries has been defined, it can only carry value information but no metadata paramaters. In other words, with entries value side being ? extends V , it's difficult to construct to a Map where you have both value and metadata information, and then apply that. Here's how it looks now in WriteOnlyMap:
CompletableFuture< Void > evalMany(Map<? extends K, ? extends V> entries, BiConsumer<V, WriteEntryView<V>> f);
Here's how it could look:
<T> CompletableFuture< Void > evalMany(Map<? extends K, T> entries, BiConsumer<T, WriteEntryView<V>> f);
By doing that, T could be flexible enough to contain both value and any extra metadata parameters. 
Infinispan issue tracking has been migrated to GitHub issues: https://github.com/infinispan/infinispan/issues
If you still want this issue to be worked on, create a new issue on GitHub and link this issue.