is the first check assertEquals( qs.getCacheHitCount(), 0 ); ? On 7 March 2018 at 17:12, Steve Ebersole <st...@hibernate.org> wrote:
> I am trying to finish up these caching and stats related changes, but am > currently fighting a few remaining test failures. In my initial > investigation IMO some of these tests are wrong, but hoped someone(s) else > could check may expectation/belief. E.g. have a look at > `org.hibernate.test.querycache.QueryCacheTest#testQueryCacheInvalidation`. > It seems to me that the assertions using stats regarding cache hit/miss/put > counts are wrong right from the very beginning. > > But I was hoping to get to a point where absolutely zero test changes were > necessary. So was hoping to get others opinions. > > The test issues a number of cacheable queries. The first time happens in a > Session in which the just queried entity is then inserted. This insertion > ought to (validly) trigger an invalidation of these already cached query > results. However the test assertions assert the opposite - that the > insertion not invalidate the cache. Possibly the old code handle this > specially (cache hit + "invalidated results") - I still need to dig into > the old code to see if that is true. But to me, anyway, that seems wrong. > Unless we add a new stat collection for query caching for the number of > times we also considered cached results invalidated due to "update > timestamps". > > WDYT? > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
