Implement Object Persistence (II)

After my first Node (DON'T) use Data::Dumper to implement Object persistence (the next above)
I understand that my first Idea is not so cool ... :-)
That there are a lot of way to make a lightweight object persistence, and Data::Dumper is the more stupid
In this version I use DBM::Deep to make the work, seems that with Data::Dumper and the eval function I have a big security hole in code
(a bad boy can substitute one object file with somethins like system ("rm -rf /") and destroy my server).
So I try to implement an Object Persistence with a db file and the class DBM::Deep.

Dump the Object

my $db = new DBM::Deep "$dumpfile" or die "Can't open Dump FILE!";
$db -> import ($probeset);
[download]

Where $probeset is a reference to an Object.

Import the Object
In another CGI script...

my $db = new DBM::Deep "$dumpfile";
my $struct = $db -> export();
[download]

And now bless the Object with the specific Class!

my $class = 'Probeset';
my $probeset = bless $struct, $class;
[download]

Hope that could be useful. Regards.
----------------><--------------------
There is nothing which cannot be answered by means of my doctrine," said a monk, coming into a teahouse where Nasrudin sat. "And yet just a short time ago, I was challenged by a scholar with an unanswerable question," said Nasrudin. "I could have answered it if I had been there." "Very well. He asked, 'Why are you breaking into my house in the middle of the night?'"

Comment on Implement Object Persistence (II) Select or Download Code

Replies are listed 'Best First'.
Re: Implement Object Persistence (II) by Joost (Canon) on Apr 29, 2005 at 14:35 UTC
(a bad boy can substitute one object file with somethins like system ("rm -rf /") and destroy my server). If anyone you don't trust has write access to the dumps you're in trouble whatever the data format and I guess that anyone with write access to the dumps can run any code he/she wants anyway. The fact that you're using DBM::Deep only removes the risk of running code from the dump - it doesn't stop anyone from breaking your application. Also, IIRC DBM::Deep doesn't really support objects, so if your probeset object contains references to other objects, they won't be blessed back. You might want to consider FreezeThaw or Storable. update: I should probably point out that neither FreezeThaw nor Storable do automatic updates to the storage if the data in the object changes, so that could be a problem. As far as I know there is no direct DBM::Deep equivalent for objects. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^2: Implement Object Persistence (II) by tucano (Scribe) on Apr 30, 2005 at 19:14 UTC
My ObjectOriented software actualy doesn't implement references to objects I will consider to add this feature (using Storable). But... Actualy I try to implments an easy way to send my DATA to other Perl scripts and Applications (like R statistical package) For this reason I try to make an easy_to_read DATA STRUCTURE (in this case4 is an HASH with reference to strings, array and other hash) Data::Dumper is OK (from HASH to FILE). DBM::Deep could be ok cause a file.db could be a reasonable solution Make other tables into my MySQL server is nota good idea cause is really overheat (I use SQL to create the object) Regards	[reply]
Re: Implement Object Persistence (II) by jZed (Prior) on Apr 29, 2005 at 17:49 UTC
You might want to look at a simple database-oriented object persistence and especially read up on the the poop group. Nice Nasruddin tale, btw.	[reply]
Re: Implement Object Persistence (II) by dragonchild (Archbishop) on Apr 29, 2005 at 15:01 UTC
I've submitted the following to jhuckaby (maintainer of DBM::Deep) as a bug report. Read more... (688 Bytes) The Perfect is the Enemy of the Good.	[reply] [d/l]
Re^2: Implement Object Persistence (II) by merlyn (Sage) on Apr 29, 2005 at 15:52 UTC
You mean, you want him to change the docs to make it very clear that DBM::Deep handles hashes and arrays only, not objects? You're trying something that is documented not to work. Your bug, not DBM::Deep, unless you think it's a doc bug. -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply]
Re^3: Implement Object Persistence (II) by dragonchild (Archbishop) on Apr 29, 2005 at 17:28 UTC
It's, at the very least a doc bug, in that the POD doesn't have this limitation in the CAVEATS. I originally thought it was an implementation bug, but the author responded and said it wasn't. So sorry, but DBM::Deep doesn't handle objects (i.e. blessed hashes). It only supports anonymous hashes and arrays. Anything blessed will not be stored blessed. I considered adding this feature, but many classes don't appreciate having their hashes tied. Its on my to-do list for a future release, however. I think it can be done, but that requires maintaining a separate metadata structure which may require a complete redesign of the file layout. The Perfect is the Enemy of the Good.	[reply]
Re^4: Implement Object Persistence (II) by merlyn (Sage) on Apr 29, 2005 at 17:34 UTC
Re^5: Implement Object Persistence (II) by dragonchild (Archbishop) on Apr 29, 2005 at 17:45 UTC
Re: Implement Object Persistence (II) by JediWizard (Deacon) on May 19, 2005 at 19:30 UTC
Have you tried Storable? They say that time changes things, but you actually have to change them yourself. —Andy Warhol	[reply]