Yes - please, guys - no System.outs!!  Use the logger if you need to.

On 22 Jul 2010, at 15:31, Emmanuel Bernard wrote:

I'd recommend to also remove the System.outs floating around as well ;)

On 22 juil. 2010, at 16:19, Israel Lacerra wrote:

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@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:


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@2af8f5
Entry is created
Entry is changed
Key, value pairing is: - test + org.infinispan.query.Pessoa@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@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@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org





_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
Lead, Infinispan
Lead, JBoss Cache





_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
Lead, Infinispan
Lead, JBoss Cache