2:30 p.m.
Hey
Infinispan's implementations of QueryIterator don't conform to the
contract of ListIterator and are pretty buggy (see
https://issues.jboss.org/browse/ISPN-2337). The most important bug is
the fact that calling next() and then previous() should return the same
element, but it doesn't.
I'm trying to fix the bugs, but have now realized that even the
interface QueryIterator is problematic.
1. QueryIterator.first()
This one isn't as problematic as the next ones, but it's strange that
calling first() and then next() returns the first element of the
collection. It would be clearer if the method were called
"beforeFirst()" or something similar.
2. QueryIterator.last()
What should the iterator return when you call last() and then call
next()? What about if you call last() and then previous()? A user would
probably call last() as the first step of iterating over the results
backwards. So calling previous() should return the last element. The
method should probably be renamed to "afterLast()".
3. QueryIterator.afterFirst() & beforeLast()
These two are OK. Calling next() after afterFirst() should return the
second element, while calling previous() should return the first element.
4. isFirst(), isLast()
ListIterator does not have the concept of "current element", but the
javadoc of all the is*() methods talk about the current element, which
is ambiguous. Therefore isFirst() and isLast() should probably be
renamed to isBeforeFirst() and isAfterLast().
5. jumpToResult(int index)
When jumping to index=1, what does next() return? What about previous()?
We should probably replace the method with two others: beforeResult(int
index) and afterResult(int index)
Any comments / other ideas?
Marko
7:03 p.m.
Hi Marko,
great observations. More comments inline:
On 24 September 2012 13:30, Marko Lukša <marko.luksa(a)gmail.com> wrote:
Hey
Infinispan's implementations of QueryIterator don't conform to the
contract of ListIterator and are pretty buggy (see
https://issues.jboss.org/browse/ISPN-2337). The most important bug is
the fact that calling next() and then previous() should return the same
element, but it doesn't.
+1, that's wrong, fix is very welcome.
Funny, one of my first contributions to Hibernate Search was rewriting
the Scrollable implementation to fix a similar problem.
I'm trying to fix the bugs, but have now realized that even the
interface QueryIterator is problematic.
1. QueryIterator.first()
This one isn't as problematic as the next ones, but it's strange that
calling first() and then next() returns the first element of the
collection. It would be clearer if the method were called
"beforeFirst()" or something similar.
+1 for "beforeFirst()"
(Hibernate's Scrollable uses the same name)
2. QueryIterator.last()
What should the iterator return when you call last() and then call
next()? What about if you call last() and then previous()? A user would
probably call last() as the first step of iterating over the results
backwards. So calling previous() should return the last element. The
method should probably be renamed to "afterLast()".
+1 for the rename
3. QueryIterator.afterFirst() & beforeLast()
These two are OK. Calling next() after afterFirst() should return the
second element, while calling previous() should return the first element.
Are you sure they are ok? I'm actually wondering why they exist at
all; they don't look like very useful to me.
Why should someone want a method to directly jump to the second element?
Users already have the option to "beforeFirst && next" or use the
"jumpTo" / seek operation.
4. isFirst(), isLast()
ListIterator does not have the concept of "current element", but the
javadoc of all the is*() methods talk about the current element, which
is ambiguous. Therefore isFirst() and isLast() should probably be
renamed to isBeforeFirst() and isAfterLast().
I would remove these too. Am I missing some use case?
5. jumpToResult(int index)
When jumping to index=1, what does next() return? What about previous()?
We should probably replace the method with two others: beforeResult(int
index) and afterResult(int index)
I would add only "beforeResult(int)", again I don't see why we should
have both versions.
Since you have to do "next()" to retrieve a value, I'd consider
"beforeResults" more user friendly than "afterResults"
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..
Sanne
10:35 a.m.
On 24.9.2012 19:03, Sanne Grinovero wrote:
> 3. QueryIterator.afterFirst() & beforeLast()
> These two are OK. Calling next() after afterFirst() should return the
> second element, while calling previous() should return the first element.
Are you sure they are ok? I'm actually wondering why they exist at
all; they don't look like very useful to me.
Why should someone want a method to directly jump to the second element?
Users already have the option to "beforeFirst && next" or use the
"jumpTo" / seek operation.
Oh yes, I was wondering about that myself when I first saw
QueryIterator, but then figured someone needed/wanted it. If we
deprecate the whole QueryIterator and introduce a new interface, I'd
leave these methods out.
> 4. isFirst(), isLast()
> ListIterator does not have the concept of "current element", but the
> javadoc of all the is*() methods talk about the current element, which
> is ambiguous. Therefore isFirst() and isLast() should probably be
> renamed to isBeforeFirst() and isAfterLast().
I would remove these too. Am I missing some use case?
I think you're right. Also, instead of calling isBeforeFirst() and
isAfterLast(), users can simply call !hasPrevious() and !hasNext(),
which already exist.
> 5. jumpToResult(int index)
> When jumping to index=1, what does next() return? What about previous()?
> We should probably replace the method with two others: beforeResult(int
> index) and afterResult(int index)
I would add only "beforeResult(int)", again I don't see why we should
have both versions.
Since you have to do "next()" to retrieve a value, I'd consider
"beforeResults" more user friendly than "afterResults"
Hmm,
what if you want to iterate backwards. If you only had
beforeResult(int), you wouldn't be able to jump behind the last element.
You'd have to use afterLast(). For usecases where you always jump to the
end and iterate backwards, afterLast() would be ok. But what if you
needed to implement a method like iterateBackwards(int fromIndex,
Visitor visitor). Then the method would need to have something like: if
(fromIndex == col.size()) it.afterLast() else it.beforeResult(fromIndex).
Of course, we could allow users to call beforeResult(col.size()), but
that's not completely clean, since there's no element with index
col.size(). But still, it may be cleaner than having an additional
method (afterResult).
> 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).
This reminds me. What is the difference between LazyIterator and
EagerIterator? Both of them execute the Lucene query immediately. The
only difference is that EagerIterator loads EntityInfos straight away,
while LazyIterator (only) loads the DocumentExtractor and then at first
invocation of next(), it loads the EntityInfo and cache value at the
same time (when filling the buffer).
IMO, the difference between them is negligible and we could either scrap
LazyResultIterator or make EagerResultIterator preload everything?
Marko
11:51 a.m.
On 25 September 2012 09:35, Marko Lukša <marko.luksa(a)gmail.com> wrote:
On 24.9.2012 19:03, Sanne Grinovero wrote:
>> 3. QueryIterator.afterFirst() & beforeLast()
>> These two are OK. Calling next() after afterFirst() should return the
>> second element, while calling previous() should return the first element.
> Are you sure they are ok? I'm actually wondering why they exist at
> all; they don't look like very useful to me.
> Why should someone want a method to directly jump to the second element?
> Users already have the option to "beforeFirst && next" or use the
> "jumpTo" / seek operation.
>
Oh yes, I was wondering about that myself when I first saw
QueryIterator, but then figured someone needed/wanted it. If we
deprecate the whole QueryIterator and introduce a new interface, I'd
leave these methods out.
>> 4. isFirst(), isLast()
>> ListIterator does not have the concept of "current element", but the
>> javadoc of all the is*() methods talk about the current element, which
>> is ambiguous. Therefore isFirst() and isLast() should probably be
>> renamed to isBeforeFirst() and isAfterLast().
> I would remove these too. Am I missing some use case?
>
I think you're right. Also, instead of calling isBeforeFirst() and
isAfterLast(), users can simply call !hasPrevious() and !hasNext(),
which already exist.
>> 5. jumpToResult(int index)
>> When jumping to index=1, what does next() return? What about previous()?
>> We should probably replace the method with two others: beforeResult(int
>> index) and afterResult(int index)
> I would add only "beforeResult(int)", again I don't see why we should
> have both versions.
> Since you have to do "next()" to retrieve a value, I'd consider
> "beforeResults" more user friendly than "afterResults"
Hmm, what if you want to iterate backwards. If you only had
beforeResult(int), you wouldn't be able to jump behind the last element.
You'd have to use afterLast(). For usecases where you always jump to the
end and iterate backwards, afterLast() would be ok. But what if you
needed to implement a method like iterateBackwards(int fromIndex,
Visitor visitor). Then the method would need to have something like: if
(fromIndex == col.size()) it.afterLast() else it.beforeResult(fromIndex).
Of course, we could allow users to call beforeResult(col.size()), but
that's not completely clean, since there's no element with index
col.size(). But still, it may be cleaner than having an additional
method (afterResult).
Right I hadn't thought about backwards scrolling. Don't you think that
being able to revert the sort order at query level is enough?
If someone needs A-Z, runs the scroll in forward mode and defines
lexicographical ordering, if you then need Z-A you revert the sort and
run the iterator again in forward only mode:
AFAIR supporting the reverse iterator in distributed lazy queries is a
nightmare, so if we agree they are pointless that's a good
simplification in the codebase.
I can think of a single use case in which one can not revert the Sort:
when the search result is defined by relevance in a fulltext query,
but in this case the revert sort doesn't make any sense as the last
results (which would get on top) are a "tail" of uninteresting
information.
>> 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?
This reminds me. What is the difference between LazyIterator and
EagerIterator? Both of them execute the Lucene query immediately. The
only difference is that EagerIterator loads EntityInfos straight away,
while LazyIterator (only) loads the DocumentExtractor and then at first
invocation of next(), it loads the EntityInfo and cache value at the
same time (when filling the buffer).
IMO, the difference between them is negligible and we could either scrap
LazyResultIterator or make EagerResultIterator preload everything?
You have to consider that Infinispan could hold many more values than
what the current node/JVM is able to keep in memory;
for example when running a distributed query, it's likely that the
user doesn't want to preload all data; obviously when running "list()"
we *could* load things lazily on access, but that gets tricky as we
don't have a close() method and I would expect people to use an
iterator if they know the amount of data retrieved is having some
critical mass.
Of course if you know you're going to hit a limited number of entries
(and these entries are of limited size - some people store hd movie
streams) then the eager loading could be more efficient.
So the lazy-loaders are needed; it could be nice to think of a
different way to specify the option; we could have something like
.iterate(LoadMode);
rather than having to define the methods twice.
Sanne
Marko
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
1:11 p.m.
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().
Marko
4 p.m.
On 25 September 2012 12:11, Marko Lukša <marko.luksa(a)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?
Sanne
Marko
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
4:01 p.m.
On 25 Sep 2012, at 15:00, Sanne Grinovero wrote:
On 25 September 2012 12:11, Marko Lukša <marko.luksa(a)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.
+1.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
4:53 p.m.
On 25 Sep 2012, at 15:00, Sanne Grinovero <sanne(a)infinispan.org> wrote:
On 25 September 2012 12:11, Marko Lukša <marko.luksa(a)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!).
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
5:39 p.m.
On 25 September 2012 15:53, Manik Surtani <manik(a)jboss.org> wrote:
On 25 Sep 2012, at 15:00, Sanne Grinovero <sanne(a)infinispan.org> wrote:
On 25 September 2012 12:11, Marko Lukša <marko.luksa(a)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 ;-)
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
b) we can't change the return type of the existing method name
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5:50 p.m.
On 25 Sep 2012, at 16:39, Sanne Grinovero <sanne(a)infinispan.org> wrote:
On 25 September 2012 15:53, Manik Surtani <manik(a)jboss.org>
wrote:
>
> On 25 Sep 2012, at 15:00, Sanne Grinovero <sanne(a)infinispan.org> wrote:
>
> On 25 September 2012 12:11, Marko Lukša <marko.luksa(a)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(a)jboss.org
> twitter.com/maniksurtani
>
> Platform Architect, JBoss Data Grid
> http://red.ht/data-grid
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
6:07 p.m.
On Tue 2012-09-25 15:00, Sanne Grinovero wrote:
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.
Projection doesn't allow you to do that as it returns an Object[]
3:49 p.m.
Can we please get a decision on this,
so we try to get something *workable* into next 5.2. release?
-Ales
p.s. since it looks like nobody is using this, apart from CapeDwarf,
my vote goes into replacing/removing the methods
4:04 p.m.
Ales,
+1 for removing it all: your vote is valuable as our most interesting user.
@Manik, I think rewriting CacheQuery is a much bigger change as I'd
expect most people to use the simpler
org.infinispan.query.CacheQuery.list() output.
Also if we deprecate the old methods, we'll need to implement them
correctly for clustered queries as well which is a massive amount of
work, not worth it since we agreed the API is useless in its current
form.
@Luksa you seem to have a solid understanding of what need to be
done.. do whatever you need to make this API make sense.
Iterable<Object> looks like the contract to go.
@Emmanuel great point, I was about screwing projections up again :-)
Cheers,
Sanne
On 26 September 2012 14:49, Ales Justin <ales.justin(a)gmail.com> wrote:
Can we please get a decision on this,
so we try to get something *workable* into next 5.2. release?
-Ales
p.s. since it looks like nobody is using this, apart from CapeDwarf,
my vote goes into replacing/removing the methods
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
4:47 p.m.
On 26 Sep 2012, at 15:04, Sanne Grinovero <sanne(a)infinispan.org> wrote:
Ales,
+1 for removing it all: your vote is valuable as our most interesting user.
@Manik, I think rewriting CacheQuery is a much bigger change as I'd
expect most people to use the simpler
org.infinispan.query.CacheQuery.list() output.
Ok, fair enough.
Also if we deprecate the old methods, we'll need to implement them
correctly for clustered queries as well which is a massive amount of
work, not worth it since we agreed the API is useless in its current
form.
@Luksa you seem to have a solid understanding of what need to be
done.. do whatever you need to make this API make sense.
Iterable<Object> looks like the contract to go.
+1.
@Emmanuel great point, I was about screwing projections up again :-)
Cheers,
Sanne
On 26 September 2012 14:49, Ales Justin <ales.justin(a)gmail.com> wrote:
> Can we please get a decision on this,
> so we try to get something *workable* into next 5.2. release?
>
> -Ales
>
> p.s. since it looks like nobody is using this, apart from CapeDwarf,
> my vote goes into replacing/removing the methods
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
4286
days inactive
4288
days old
infinispan-dev@lists.jboss.org
13 comments
6 participants
participants (6)
-
Ales Justin -
Emmanuel Bernard -
Manik Surtani -
Marko Lukša -
Mircea Markus -
Sanne Grinovero