http://qs1969.pair.com?node_id=845952

chexmix has asked for the wisdom of the Perl Monks concerning the following question:

Good day, Monks -

Where I work we have a set of Perl scripts that access a small number of Sybase databases in order to do various things (usually to return a result set). There isn't a huge range of needs here - in fact the routines are almost all similar enough that I've been asked to abstract them out into an OO Perl module so that our code can be more efficient and uniform going forward.

To put it bluntly, I'm kind of lost. I I'd gotten to the point where I had a (sort of working) module that made use of SQL::Abstract, but then hit a wall when it appeared SQL::Abstract didn't handle "group by."

So I went looking for something to replace SQL::Abstract, and ran smack into DBIx::Class.

Thing is, DBIx::Class is (or seems to be) ginormous, & what with me being a newbie to module writing and OO Perl, I kinda ... can't see what the best way into that particular castle might be. In fact there is so much to DBIx::Class that I'm wondering whether it isn't overkill for a little local-use module like I want to write.

FWIW, the wishlist for the module is as follows:

So there you have it. As previously stated, I am newish to module writing and am feeling lost. Is looking at something like DBIx::Class the Right Thing to do here? & if it is, what's the best way to start?

I confess that I often feel so unskilled that I don't even know how to ask the right questions.

Thanks for any Words of Monkish Wisdom.

Replies are listed 'Best First'.
Re: lost in my first Perl module
by ikegami (Patriarch) on Jun 22, 2010 at 19:53 UTC

    Looking at your wish list, you're not abstracting anything away at all. You're just adding a needless layer.

    open a DBI connection given a hostname, database, username and password;

    DBI->connect

    the user (if in an interactive context) for any of the four things above if missing;

    Bad idea. Data storage and user interaction are unrelated tasks.

    supply a method for preparing a query;

    $dbh->prepare

    supply a method for executing a prepared query;

    $sth->execute

    allow the user to just call DBModule::run_query("select ... from ... where ...") and expect the module to properly prepare/execute

    If $dbh->prepare + $sth->execute is really a hardship,

    sub do_select { my($dbh, $statement, $attr, @bind_values) = @_; my $sth = $dbh->prepare($statement, $attr) or return undef; $sth->execute(@bind_values) or return undef; return $sth; }

    while helpfully handling / trapping Sybase error codes

    RaiseError => 1

    supply a method to reformat the result set into various hashes/arrays

    $dbh->selectall_*

    supply a method to release a result set (equiv to $sth->finish()

    $sth->finish, though rarely needed.

Re: lost in my first Perl module
by Anonymous Monk on Jun 23, 2010 at 17:17 UTC

    Like ikegami said, you probably just want to use DBI.

    If you needed to write an object-oriented module, I'd recommend Moose, but it doesn't sound like you need to.

    To get started (if you actually don't need an OO module), just create yourself a SybaseManip.pm file, put package SybaseManip; at the top of it, and start writing some subs to do your bidding. To use your code from a test script, just put this at the top of said script:

    use lib 'path/to/where/SybaseManip.pm/lives'; use SybaseManip;

    and start calling your functions.

      Forgot to mention: when you call your functions in your test script (for the setup described above), you'll need to fully-qualify their names, as in: SybaseManip::my_func(...).

      And if you have any globals in your SybaseManip.pm file (as in: our $foobar = 'baz';), you can access them from your script similarly: $SybaseManip::foobar