Re^3: Never use Storable to save XS objects

in reply to Re^2: Never use Storable to save XS objects
in thread Never use Storable to save XS objects

I think you need to answer a couple of questions first:

What do you expect to happen when you serialize the DB connection? Should the DB connection be closed? What should be stored in the serialized data structure?
What do you expect to happen when you de-serialize the DB connection? Should the connection happen immediately? What about waiting until the first query because you may not actually use the DB connection at every given de-serialization.

There are some further concerns:

Should passwords be stored? If so, how?
How should DBI connections using DBD::Excel or DBD::CSV work?
What should happen if you de-serialize the thing and attempt to use the DB connection on a box that doesn't have the right things installed?

And I'm sure that I'm missing some concerns. In other words, serializing stuff that uses external resources is non-trivial. I've run into the same problem with DBM::Deep and I don't have a really good way to solve it as of yet.

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re^3: Never use Storable to save XS objects

Replies are listed 'Best First'.
Re^4: Never use Storable to save XS objects by robins (Acolyte) on Nov 08, 2007 at 18:00 UTC
Well, basically, I don't want to store the database connection at all. When I store I want the database connection to be ignored (or filtered out), and when I thaw I want the object to use the currently open connection in the application. I need to store Perl objects, and for some reason I end up with code references in what I'm storing, and my debugging have shown that it is DBI handles. If you know of a good and generic way to create a Perl object that uses DBI handles for some of it's method, but allow the object itself to be stored via Storable I'm more than open to some pointers to good documentation. There is a good chance that my constructor is designed in a way that I end up with code references that I do not need.	[reply]
Re^5: Never use Storable to save XS objects by dragonchild (Archbishop) on Nov 08, 2007 at 18:36 UTC
If you already have a $dbh open in your app, then pass it in to all the methods instead of passing it into the object's constructor. Why should the object know about the $dbh if you don't ever want to serialize it? My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]

In Section Meditations