[infinispan-dev] QueryIterator inconsistencies

[Manik Surtani]

On 25 Sep 2012, at 16:39, Sanne Grinovero <sanne at infinispan.org> wrote:

> On 25 September 2012 15:53, Manik Surtani <manik at jboss.org> wrote:
>> 
>> On 25 Sep 2012, at 15:00, Sanne Grinovero <sanne at infinispan.org> wrote:
>> 
>> On 25 September 2012 12:11, Marko Lukša <marko.luksa at gmail.com> wrote:
>> 
>> On 25.9.2012 11:51, Sanne Grinovero wrote:
>> 
>> Any comments / other ideas?
>> 
>> Marko
>> 
>> That's a lot of changes needed. One would say we could deprecate all
>> methods and rewrite the new ones, but wouldn't it be better to
>> deprecate the interface and introduce a brand new one?
>> What about "ResultsIterator" ? after all, we're not iterating on queries..
>> 
>> I agree. The only thing that bothers me is that CacheQuery would then
>> need new methods called (lazy)resultIterator() (instead of iterator(),
>> which already exists).
>> 
>> Right. though I like "resultIterator()" more so we're having luck in
>> this case ;)
>> 
>> Any better suggestion for names? Anyone thinks it's worth to remove
>> the old ones without a deprecation step to reuse the old names?
>> 
>> One thing to keep in mind is that CacheQuery extends Iterable, therefore
>> a lot of users will actually implicitly invoke the iterator() method.
>> This pretty much means we should not introduce resultIterator().
>> 
>> 
>> Looks like we have to break backwards compatibility. From the look of
>> how this API was, I guess not many users dealt with it before you, so
>> I'm fine with that, I don't see how else we can fix this API.
>> 
>> While at it, it would be nice to see if we can change the signature
>> from "extends Iterable<Object>" to return an iterator on the types
>> compatible with the values of the cache, since the Cache supports
>> proper generics.
>> 
>> To deal safely with Iterable, I think it would be better to default to
>> lazy loading mode and to provide an overloaded method which allows to
>> specify a loading mode.
>> 
>> Anyone having a better idea which allows to not break backwards
>> compatibility?
>> 
>> 
>> Not really - I think compatibility will break, sadly.  :/
>> 
>> One option to maintain compatibility is to keep the existing QueryIterator
>> and mark it as deprecated, and write a new iterator, maybe call it a
>> ResultIterator (which is more accurate anyway!).
> 
> Your screen is too small ;-)

Ah, could be the way Apple Mail collapses threads.

> That was suggested above ^^ but isn't possible as
> a) we can't change the method name as it would break the fact
> CacheQuery implements Iterable

Maybe move the change one step higher: deprecate CacheQuery and replace that interface with (suggestions?).

> b) we can't change the return type of the existing method name



> 
>> 
>> --
>> Manik Surtani
>> manik at jboss.org
>> twitter.com/maniksurtani
>> 
>> Platform Architect, JBoss Data Grid
>> http://red.ht/data-grid
>> 
>> 
>> _______________________________________________
>> 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

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20120925/877a4450/attachment.html