in reply to Save a statement handle to a file and open it again as a 'cursor' or something.

If this is an RFC for the need for such a module, would you mind pointing out where it's better, worse, different, or meant for a different purpose than DBD::AnyData, DBD::CSV, DBD::RAM, DBD::Mock, DBD:Sponge, DBD::Sprite, and a handful of others I'm probably missing?

It's not that I'm knocking what you're doing. I'm just nto sure what we're being asked to evaluate and along what lines.

  • Comment on Re: Save a statement handle to a file and open it again as a 'cursor' or something.

Replies are listed 'Best First'.
Re^2: Save a statement handle to a file and open it again as a 'cursor' or something.
by uber_spaced (Novice) on Aug 23, 2007 at 19:15 UTC

    DBD::Anydata appears to be for interacting with specified types of files as databases. SthFile just saves a statement handle as a cursor that can be opened at a later time.

    DBD::CSV changes NULL values to empty strings. SthFile saves the actual array returned from the statement handle. NULL values are undefs.

    DBD::RAM (from the documentation) pulls the entire data structure into memory. SthFile streams it.

    DBD::Mock just makes the a database handle that 'looks like' it worked.

    DBD::Sponge makes a handle out of perl data that is already in memory. SthFile's streams data into memory.

    DBD::Sprite appears to require you to create a table with definitions before saving stuff to the file. SthFile just streams a statement handle to disk, and then reads it from disk.

    A future modification will probably involve allowing an open handle of any type to be the output or input of SthFile.

    I already know something like this would be useful to me. One of the things I'm wondering is if I should make it as an extension for other dbd drivers that automatically save a statement handles meta data.

[reply]
      It does sound handy when you state it like that.

      I'm not sure how you mean to make it an extension for other DBDs.

      Do you mean you'd make it so you can load this module separately, take the existing statement handle from any other DBD, and stuff it into a file with this for later retrieval, without modifying the other DBD? That would be very handy sometimes..

      If you mean you'd have this subclass another DBD and add this functionality, and you'd just have to specify in your constructor what DBD you're using, that could be handy, too. If you could get that into from DBI, that could be even better.

      If you're asking if you should try submitting patches to a bunch of other DBD authors, that's probably a bad idea if for no other reason than you'd never be able to keep up with all of them.

      Sorry if I'm dense today. I feel like I'm making this harder for myself to understand than is necessary. I'm not trying to do that. Maybe a little less pizza at lunch next time... I do feel a bit groggy.

[reply]

        Understandable.

        What I'm looking to do is save as much data about the STH as possible. MySQL returns the number of rows that it found, Oracle doesn't. That makes me question whether or not there is a simple way to figure out what methods are available in every DBD type and how to save them to a file.

        Because this implementation is very simple, it doesn't strike me as something that's difficult to incorporate as some sort of extension to DBI or DBD or whatever.

        At the very least, a person, no matter what database driver they are using should be able to save the contents of a handle to disk and open it back up again. The supporting code to do this very basic thing minimally involves storing $sth->{NAME} and then the records that follow.

        I need to know how to proceed. As a standalone module, it's pretty nifty. As a thing that's available in DBI it would be pretty cool.

        I'm new to submitting modules to CPAN. I'm new to the inheritance model of Perl (i've written some things, but I don't want to write anything offensive).

[reply]

In Section Meditations