Re: [infinispan-dev] Query: inconsistencies with putAll
On 27 Mar 2012, at 14:51, Sanne Grinovero wrote:
Hi all,
I was adding some tests for Query as I just found many basic
operations are uncovered, and found an annoying issue.
When using
cache.putAll(values);
the Query interceptor will iterate on each entry, transform each entry
key and replace those entry keys in string form with the new indexed
values.
The problem is *which index* : the index mapping information is bound
to the indexed type. So the normal put/replace/remove operations
actually rely on the return value to know where to direct the proper
index operation (to which index) - if any.
So even operations where return values are suppressed won't work?
With putAll() returning void, I don't have the return values.
I could hack this to "unroll" in several individual put() operations
but I don't think that should happen in an interceptor. Also this
would defeat the purpose of using putAll, killing it's efficiency over
using several put operations.
No, that's no good…
I would generally expect people to put objects of the same type when
replacing a key.. so this works fine usually looking at the runtime
type of the new value (as it's doing), but it's not correct generally.
Worse, I can't detect the mismatch and log some warning.
Why is that not correct? IMO, working on the type of the new value is more correct than
doing so on the old value …
Any suggestion? I'm tempted to say I need to retrieve all previous
values. I actually need only the types :-/
A simple solution would be to disallow using multiple indexes for the
same cache, but that's not a welcome change. I'd prefer to throw an
exception on putAll : not supported when indexing is enabled.
You could also maintain a type map? Keys -> Type. But that's unnecessarily
voluminous. What's wrong with working off the type of the new value? Are you
concerned about the types changing and hence not being able to clean up stale indexes?
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org