[ http://issues.apache.org/jira/browse/IBATIS-363?page=comments#action_12447111 ] Clinton Begin commented on IBATIS-363: --------------------------------------
I had a look at this. It's not a simple fix. Generally speaking, I would hope that this is a really rare requirement. It's basically a cache override scenario. What this is saying to me is "I want iBATIS to cache my objects, but sometimes I want to control the lifecycle of certain instances". Honestly, I'm borderline thinking this may be one of those things that we just say..."don't do that". Like really, the three scenarios are: A) Return the cached object despite the resultObject parameter (current behavior). B) Ignore the cache, run the query and load the data into the resultObject. C) Fetch the object from the cache and copy the data based on the result map. Option C actually makes the most sense. But honestly, I really wonder why we'd ever do this. To be honest, I wish I had never created the resultObject version of that method, as it really is kinds silly. I think my original thought was for row-by-row handling within a rowhandler, a single result object could be used in the case of aggregate processing. That was back when I thought object instantiation was expensive (and perhaps it was back then). But it's not much of a performance concern anymore. I'm going to vote that we don't change this behavior, and maybe even deprecate this method. .... thoughts? > Caching problems when providing resultObject to queryForObject(...) > ------------------------------------------------------------------- > > Key: IBATIS-363 > URL: http://issues.apache.org/jira/browse/IBATIS-363 > Project: iBatis for Java > Issue Type: Bug > Components: SQL Maps > Environment: All > Reporter: Brandon Goodin > Assigned To: Brandon Goodin > > I'm not sure if anyone else has ran up against this. But, there is a problem > when using queryForObject(id, parameterObject, resultObject) and caching. > I have code that does the following: > public class Monster { > private String monsterName; > private Integer ferocityLevel; > private Integer height; > ... > //getters/setters > ... > } > public class MonsterService { > ... > public Monster getMonster (String monsterName) { > Monster monster = new Monster(monsterName); > return monsterDao.fetch(monster); > } > ... > } > public class MonsterDao { > ... > public void fetch (Monster monster) { > queryForObject("Monster.fetch", monster, monster); > } > ... > } > The first time I call MonsterService.getMonster("Godzilla"), all is fine > because the Monster object is not yet cached in iBATIS. The normal means of > populating the supplied resultObject is employed. But as soon as the object > is cached it never populates my resultObject beyond the monsterName that i > provided. Basically, when getCacheKey(request, parameterObject) is called it > returns the monster object appropriately. The only problem is that it never > populates the supplied resultObject. It simply returns the cachedObject which > would be fine if I wasn't providing a resultObject that i expected to be > populated. In other words, I'm not looking for a returned object I'm looking > for my supplied object to be populated. > -- CachingStatement -- > ... > public Object executeQueryForObject(RequestScope request, Transaction trans, > Object parameterObject, Object resultObject) > throws SQLException { > CacheKey cacheKey = getCacheKey(request, parameterObject); > cacheKey.update("executeQueryForObject"); > Object object = cacheModel.getObject(cacheKey); > if (object == CacheModel.NULL_OBJECT){ > // This was cached, but null > object = null; > }else if (object == null) { > object = statement.executeQueryForObject(request, trans, > parameterObject, resultObject); > cacheModel.putObject(cacheKey, object); > } > return object; > } > .. > -- > We could provide a means either in the CachedStatement class or upstream in > the SqlMapExecutorDelegate to handle the translation from the cached object > values into the supplied resultObject. > Thoughts? > Brandon. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
