On Saturday 29 December 2001 00.45, Joe Cooper wrote:
> Because I need to be able to retrieve the object entry based on it's
> hashed key (otherwise I would need a separate record for each object to
> point from the URL to the hashed entry).
And the point being?
store.log has the hash, why compute it again?
> I will describe what I'm trying to accomplish which might make it more
> clean why I need to be able to match the hash:
>
> I'm making a utility that will provide invalidation services for Squid.
> The first is simply an indexer that tails the store.log, watching what
> hits the disk. The second is an invalidation server that accepts a
> request of a specific form (eventually will follow whatever invalidation
> standard comes into existence, but for now will simply be a tweaked HTTP
> server) and sends an appropriate PURGE request or batch of PURGE
> requests to Squid to invalidate the objects that need to be invalidated.
>
> The reason I need the hash is because in order to provide "full tree"
> deletion (i.e. PURGE sub1.domain.com and all of its subdirectories) I
> have to keep a linked list of items in the tree. So my database will be
> a key=value Berkeley DB that looks a little like this:
Ah.. now you are providing some interesting details. Limited indexing
capabilities in the selected database format.
> MD5-Hash=URL exists|empty-parent children hashes ...
I would probably use at least two tables.
1: Cached URL tree
2: MD5 -> URL table
with a garbage collector on the MD5 -> URL table
But your design should also work I think.
Regards
Henrik
Received on Fri Dec 28 2001 - 19:05:22 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:42 MST