From: Ian B. <ia...@co...> - 2003-10-27 21:25:19
|
On Monday, October 27, 2003, at 02:55 PM, Sidnei da Silva wrote: > | 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 think there's maybe some confusion about the different objects. First, caching happens per-connection. Which means each transaction has its own cache, if you are using transactions. If you create an object by a certain ID in a transaction, any attempt to get that object by that ID from the same transaction will give you back the same object you got before, guaranteed. But in a different transaction you will get a different object, since the two transactions are isolated. It just occurred to me there's some sloppiness when it comes to committing or rolling back a transaction. The objects stick around, but once you've finalized the transaction I don't know what use they are. Those instances should actually be invalid. Unless you assume that by committing or rolling back a transaction, you are implicitly restarting the transaction and can keep using it. Anyway, I don't think this applies to this circumstance, but it should be worked out. So -- attributes changes immediately update the database. They also update the internal cache of that column. Other instances that are in other transactions are not effected. They aren't effected when you commit the transaction. It seems like at some point they should be effected (expired, perhaps), but I'm not sure where. > 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. SQLObject should already handle this, at least for an individual instance. It knows when you change an attribute and updates its own cache. I imagine ObjectModified is meant for something like ZODB, where persistence is added more transparently to an instance (the expense being that something must be watching the instance and telling it when it's been changed). I think SQLObject can ignore that message, as instances are self-aware. -- Ian Bicking | ia...@co... | http://blog.ianbicking.org |