The iBatis caching key is based on the SQL query that is sent to the database. The full results are cached under that key in the particular specified CacheModel. It does not retain the individual object dentity (OID) of all the individual objects returned in a query. This means that if you have an update that will affect the verasity of a cache... it flushes the whole cache. There is a whole world of behavior that comes along with OID that we do not support. Currently we have no plans on supporting OID and will likely never have plans to support it.
That being said there has been some talk of updating the caching system in the next release of iBatis to allow for more robust caching implementations to be more easily plugged in. Perhaps in the future it will more possible for users to spin their own cache key generation and manage the cache on whatever level they desire. Thanks, Brandon On 5/22/05, Oscar Picasso <[EMAIL PROTECTED]> wrote: > Is there a way to invalidate a cache entry on update? > > Let say I have the following select using a cache model (result class = User): > > select id, username, password from users where useraname = #username#; > > and the following update (parameter class = User): > > update users > set password = #password# > where username = #username# > > Following an update, I want the select statement to retrieve a fresh User but > I > don't want all the cache entries to be flushed. > > I cannot make it work: the select statement returns the 'old' user. > > At first I though that this was the purpose of a read-write cache. But I am > under the impression that read-write caches are unrelated to the invalidation > of particular cache entries on inserts or updates. > > Am I right? > > Any idea of how to do what I want? > > Oscar Picasso > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com >
