Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Re^2: Never use Storable to save XS objects

by robins (Acolyte)
on Sep 17, 2007 at 10:20 UTC ( #639375=note: print w/replies, xml ) Need Help??


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

You shouldn't by any chance have some documentation about how you solved that hurdle?

I have the DBI problem myself. My objects contain DBI handles, and I need to serialize them, but without the DBI code.

Is there maybe a module in the DBI or Class namespace that can help with this? Any pointers appreciated...

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

Replies are listed 'Best First'.
Re^3: Never use Storable to save XS objects
by dragonchild (Archbishop) on Sep 17, 2007 at 13:56 UTC
    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:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

      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.

        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:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://639375]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (4)
As of 2023-04-01 04:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?