[infinispan-dev] Query: inconsistencies with putAll

[Sanne Grinovero]

On 27 March 2012 15:37, Manik Surtani <manik at jboss.org> wrote:
>
> 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?

Depends, most cases will work anyway, but definitely some cases could
misbehave when suppressing return values.
I guess my next answers explain this better..


>> 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 …

Yes I definitely need the type of the new value to index the one one;
but I also need the type of the previous value if it existed, to know
how to cleanup existing index entries.


>> 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?

Exactly: the problem is with cleanup of previous index entries.
Granted I don't expect this to be common; personally I would favour an
application design in which - for a specific key - the type of the
value could be determined by the key.
But if you expect to support this:

put( "name one", new SomeStuff("value") );
put( "name one", new SomeDifferentStuff("value") );

then, iff SomeStuff and SomeDifferentStuff are using different index
names A and B, the second put needs to know the type of the previous
value to remote "name one" from the index A while adding the new value
to index B.

For this to work I'm "having a look" at the type of the return value of the put.

So indeed if
a) you're suppressing return values
b) two different types are indexed on different indexes
c) you're reusing the same key instance for a different type

then you get in trouble. Of course that's not common, and there are
many workarounds but tricky to explain; worst of all, I can't detect
the problem and warn.

Cheers,
Sanne


> Cheers
> Manik
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev