From: Sidnei da S. <si...@aw...> - 2003-10-27 21:03:04
|
| SQLObject.expire() expires the *instance's* cache of its column values. Oh, I didn't notice there was an instance cache as well. | When you create an instance, it gets its column values from the | database immediately. When a transaction is rolled back we expire all | the effected instances' caches so that they don't contain stale | information from a rolled-back transaction. (There perhaps should be | other circumstances where we automatically expire instances, but I | haven't thought that through). | | The per-connection cache is a different issue. | | I'm not sure what SQLObject should do for an ObjectModified message. | What does this message mean? There's also the issue of non-column | instance variables (which you might manually add to a SQLObject | subclass) and rolling those values back... that might be related, or | maybe you are avoiding that issue entirely for the moment. I'm starting to get a feeling that the issue is deeper than I thought :) Last time I checked there was a cache for attributes, so when you changed an attribute it wasn't immediately updated on the database, -- or it was updated immediately on the database, but objects could still fetch old values from the cache -- I'm not exactly sure what was it. I'm not using any non-column instance variable (or at least, no meaningful ones). An ObjectModified message would be generated anytime an object was modified, like when setting a column instance variable. This would trigger clearing the cache for that instance and maybe mark the instance as modified. The intent IMHO, is to avoid reading from the database as much as possible, probably having all the column variables in cache, and renewing all of them in a single step when the cache gets cleared. I haven't really looked that deeply into the caching implementation. []'s -- Sidnei da Silva <si...@aw...> dreamcatching :: making your dreams come true http://awkly.org The Macintosh is Xerox technology at its best. |