in reply to Implement Object Persistence (II)

(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?"

Replies are listed 'Best First'.
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]

In Section Cool Uses for Perl