[infinispan-dev] Query: inconsistencies with putAll

[Manik Surtani]

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 at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org