Re: [Poop-group] Re: Persistent storage (storable preferred as mechanism)

David Nicol wrote: My gripe with Storable is that it is not possible to access into the storable object without thawing the whole thing. An idea has just occurred to me however, which is, it may be possible to create some kind of tie wrapper that would appear to be thawing a Storable object, bu

Re: Persistent storage (storable preferred as mechanism)

> My gripe with Storable is that it is not possible to access into the Break the structure into smaller pieces (e.g., a heavily nested hash into separate values) and store them individually. This works nicely with a database backend using blobs to manage access to the frozen data. -- Steven

Re: Persistent storage (storable preferred as mechanism)

On Mon, 11 Jul 2005, David Nicol wrote: My gripe with Storable is that it is not possible to access into the storable object without thawing the whole thing. An idea has just occurred to me however, Ideas are great but Have you actually benchmarked Storable ? Its pretty fast indeed. I

Re: Persistent storage (storable preferred as mechanism)

On Mon, 2005-07-11 at 12:48 -0500, David Nicol wrote: > My gripe with Storable is that it is not possible to access into the storable > object without thawing the whole thing. So use Data::Dumper or XML, if that's what you want. If you want speed, use Storable. - Perrin

Re: Persistent storage (storable preferred as mechanism)

On 7/9/05, Perrin Harkins <[EMAIL PROTECTED]> wrote: > Steven Lembark wrote: > > Also the dumped data is not (usually) > > transferrable between platforms. > > It has always worked for me if I use nfreeze() instead of freeze(). > > - Perrin My gripe with Storable is that it is not possible to ac

Re: Persistent storage

Steven Lembark wrote: Also the dumped data is not (usually) transferrable between platforms. It has always worked for me if I use nfreeze() instead of freeze(). - Perrin

Re: Persistent storage

> Seconded. Storable has no competition. Main problem is its advantage: lower overhead than Data::Dumper but you cannot look at it to tell what's in the thing. Also the dumped data is not (usually) transferrable between platforms. --

Re: Persistent storage

Great. I'm using Storable now in a test environment. Thanks for reckoning. On Friday 08 July 2005 08:19, Perrin Harkins wrote: > On Fri, 2005-07-08 at 07:15 -0400, Steven Lembark wrote: > > > So far, I've avoided using Data::Dumper (and eval) and just used > > > 'split' with stored comma-delimi

Re: Persistent storage

Depending on how advanced your serialisation needs are, you might have a look at Data::Dump::Streamer (http://search.cpan.org/~yves/Data-Dump-Streamer-1.14/). Yves has put quite a lot of work into making it handle just about every twisted case you can devise; this includes sane dumping of closures

Re: Persistent storage

On Fri, 2005-07-08 at 07:15 -0400, Steven Lembark wrote: > > So far, I've avoided using Data::Dumper (and eval) and just used 'split' > > with stored comma-delimited hashes or generated require-able packages > > with everything "ready". But now that we're under mod_perl, I'd like to > > find a f

Re: Persistent storage

So far, I've avoided using Data::Dumper (and eval) and just used 'split' with stored comma-delimited hashes or generated require-able packages with everything "ready". But now that we're under mod_perl, I'd like to find a faster, safe way do this without needing to use Apache::Reload or other

Persistent storage

Are there any peculiarities or recommendations with using either YAML, Storable (or another means) to efficiently store session hashes and bring them back to life safely from rdbms (mysql)? So far, I've avoided using Data::Dumper (and eval) and just used 'split' with stored comma-delimited hash