[infinispan-dev] [ISPN-548] Discussion on updating the QueryInterceptor to be able to update old keys

[Israel Lacerra]

So, it is not a problem in my code.

Navin, changing the two ifs (if(entry.isCreated())...if(entry.isChanged()),
to if(entry.isCreated())/else my tests works fine.

thanks!
Israel

On Thu, Jul 22, 2010 at 10:58 AM, Manik Surtani <manik at jboss.org> wrote:

> entry.isChanged() returns true if the entry is, well, changed.  Changed
> includes {created, modified, removed}
>
> entry.isCreated() only returns true if the entry has just been created in
> the scope of the invocation.
>
> See the Javadocs for details:
>
>
> http://docs.jboss.org/infinispan/4.1/apidocs/org/infinispan/container/entries/CacheEntry.html#isChanged
> ()
>
> http://docs.jboss.org/infinispan/4.1/apidocs/org/infinispan/container/entries/CacheEntry.html#isCreated
> ()
>
> Cheers
> Manik
>
> On 22 Jul 2010, at 14:45, Israel Lacerra wrote:
>
> Navin,
>
> I update my trunk and I still have a little issue. But, maybe, it's a
> problem in my code, cause I had to change the order of QueryInterceptor.
> This line: cache.getAdvancedCache().addInterceptorAfter(inter,
> LockingInterceptor.class); in QueryHelper did not work for me, because
> somehow the LockingInterceptor was not in the interceptor chain yet.
>
> Anyway, putting the same key twice:
>
> "Key, value pairing is: - test + org.infinispan.query.Pessoa at 2af8f5
> Entry is created
> Entry is changed
> Key, value pairing is: - test + org.infinispan.query.Pessoa at 1088a1b
> Entry is changed"
>
> entry.isChanged() is always returning true. But, like I said, maybe it's a
> problem with my changes.
>
> I will see it more carefully tomorrow...
>
>
> Israel
>
> On Thu, Jul 22, 2010 at 10:09 AM, Manik Surtani <manik at jboss.org> wrote:
>
>>
>> On 21 Jul 2010, at 12:54, Navin Surtani wrote:
>>
>> > 1 - User does a put()
>> > 2 - Interceptor checks the set of keys used within the same context to
>> > see if the same key has been used
>> > 3 - If it has an UPDATE is used.
>> > 4 - If not we do an ADD.
>>
>> Sorry, just saw this.  To confirm, this should work even beyond the scope
>> of a single invocation, and even a single transaction, correct?  E.g.,:
>>
>> Tx1:
>>        1) creates a NEW entry using cache.put()
>>        2) new entry is indexed
>>
>> Tx2 (potentially at a later date):
>>        1) updates the entry using cache.put()
>>        2) the index should be updated
>>
>> So to that end, just checking the presence of the entry in the invocation
>> context is not good enough - all it will tell you is whether the entry was
>> touched within the same scope (whether that scope is an invocation or a
>> transaction is irrelevant).
>>
>> Mircea's solution of testing entry.isCreated() is a valid one.
>>
>> Cheers
>> Manik
>>
>> --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100722/1297d2a4/attachment-0001.html