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

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(a)jboss.org&gt; 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/ent... > http://docs.jboss.org/infinispan/4.1/apidocs/org/infinispan/container/ent... > > 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(a)jboss.org&gt; 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(a)jboss.org >> Lead, Infinispan >> Lead, JBoss Cache >> http://www.infinispan.org >> http://www.jbosscache.org >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev