"Charles Hixson" <charleshixsn / earthlink.net> schrieb im Newsbeitrag 
news:4142336A.4040005 / earthlink.net...
> Sort of.  The disk storage is permanent, it's the hash that's temporary. 
> I certainly wouldn't want to eat up my ram by holding the entire database 
> in ram, when at any one time it didn't need most of it.

Ah, ok, that sounds as if you needed a cache.  An LRU cache is relatively 
straightforward.  There might be one on RAA.  I remember I did an 
experimental implementation once, if you're interested I can check whether I 
still have it.

> OTOH, a persistent hash would be a reasonable answer...well, I haven't 
> looked at your code yet, so I shouldn't comment.  It sounds like it would 
> be a reasonable answer.  I haven't been planning to persist the hash 
> itself, but if I can, without excessive cycle use, then that would just by 
> itself solve the current problem.  (OTOH, it also looks like
> ..
>    at_exit    {  flush  }      #   this is run after the files are opened 
> and the hash is initialized
>  end  #  initializer
> ..
> end  #  class
>
> will solve the problem.   I've read the description of what it does three 
> times, and I still can't be *sure* that the file and class variables will 
> still be extant when I run it, but it looks like that's the intent.

The only thing that at_exit can't help you with is a crash.  If for some 
reason (e.g. buggy extension) Ruby crashes at_exit won't help you here.  The 
best (i.e safest) is probably to directly store new data in the DB and keep 
a cache of recent used data in mem.

> Thanks for your assistance.

You're welcome!

Kind regards

    robert