Changes between Version 7 and Version 8 of TracDev/Proposals/CacheInvalidation

Timestamp:

Mar 17, 2009, 10:36:47 PM (15 years ago)

Author:

Remy Blank

Comment:

Added comments.

TracDev/Proposals/CacheInvalidation

@@ -111 +111 @@
 I've also added more documentation to the decorators and changed the order of the definitions in a top-down way (first the decorators, then the descriptors, ending with the proxy class), as I think it's easier to understand that way.
 
+==== rblank ====
+Thanks for the improvement ideas, I'll integrate them shortly.
+ - I'm not sure the DB race condition you describe can actually happen. At least with SQLite, issuing a `SELECT` sets the lock state to `SHARED`, which disallows writes, so it should not be possible to increase the generation between the data retrieval and fetching the generation. I don't know how this behaves with other databases, though. Maybe it's just safer to fetch the generation first.
+
+ - You're right about automating the cache key generation. I didn't want to do it first, because renaming a module or class would have changed the key. But we're not going to rename them, and even if we do, it will only leave an orphaned row in the `cache` table, so it's no big deal. Your patch proposed `{module}.{function}` as the key, I'd like to make it `{module}.{class}.{function}`.
+
+ - If the keys are auto-generated, the decorators don't need any arguments anymore. This allows simplifying them even more by dropping the `cached()` and `cached_value()` functions, and calling the descriptor classes `cached` and `cached_value` directly.
+
 == Idea 2: Cache control ==