[infinispan-dev] Remote Iterator design doc

[Sanne Grinovero]

Passing a type isn't too unusual. But what happens if the returned
content is actually of another type?

I would have such a method to also imply a filter on the type, that's
also useful in practice: either it's just a safeguard for when it's a
mono-type cache, or if the user wants to store multiple types in the
Cache he will probably need a type filter anyway.

BTW the CloseableIterator is what it is because we created that in
Infinispan Query; it's nothing more than an Iterator (which is also
type) but which makes it very clear to the user that resources will
leak if it's not closed properly.
It's a nice idea to reuse the contract for consistency, if it works
out. And of course we can evolve the Query API as well if we get
better ideas now.

-- Sanne


On 8 May 2015 at 20:37, William Burns <mudokonman at gmail.com> wrote:
> That is a good point, Galder.  Unfortunately the return type is lost since
> we only pass a name for the filterconverter factory instead of the converter
> which contains the type.  We would have to allow the code to specify the
> type in the assigned variable it is returned to or ask for a Class instance
> to be passed for inline type inference.
>
> <E> CloseableIterator<E> retrieveEntries(...)
>
> CloseableIterator<E> retrieveEntries(..., Class<E> returnType)
>
> :(
>
>  - Will
>
>
> On Thu, May 7, 2015 at 11:07 AM Galder Zamarreño <galder at redhat.com> wrote:
>>
>> Looks good, but had a question.
>>
>> CloseableIterator is typed as CloseableIterator<E>, what's the type that
>> the method would return? I guess that would be dependant on the converter?
>> How are you going to represent that?
>>
>> Cheers,
>>
>> > On 28 Apr 2015, at 16:46, Gustavo Fernandes <gustavo at infinispan.org>
>> > wrote:
>> >
>> > Hi all, just updated [1]
>> >
>> > Comments and feedback appreciated!
>> >
>> > [1] https://github.com/infinispan/infinispan/wiki/Remote-Iterator
>> >
>> > Thanks,
>> > Gustavo
>> >
>> > _______________________________________________
>> > infinispan-dev mailing list
>> > infinispan-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> --
>> Galder Zamarreño
>> galder at redhat.com
>>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev