david.jackson has asked for the wisdom of the Perl Monks concerning the following question:

Greetings --

Some guy has been posting questions to the MySQL list. What's is this OO-Perl, or what? I don't use this parm when I work DBD/DBI?

If it is OO does it requre a different ver of Perl or Modules? How would your basic DBI connect functions translate:

use DBI; use diagnostics; use strict; my ($dbh,$sth); my ($dbname)="pickle"; my ($login)="picklesql"; my ($password) ="pi56fb"; my (@ary); # $dbh = DBI->connect("DBI:mysql:$dbname",$login,$password) or die "Can't connect to $dbh: $dbh->errstr\n"; $sth = $dbh->prepare("SELECT * FROM catalog") or die "Can't connect to $dbh: $sth->errstr\n"; $sth-> execute() or die "Can't connect to $dbh: $sth->errstr\n"; $sth -> finish(); $dbh->disconnect();
Thanks, David

Edit ar0n -- fixed formatting

Replies are listed 'Best First'.
(jeffa) Re: use Objects:: MySQL ?
by jeffa (Bishop) on Jan 02, 2002 at 04:22 UTC
    Hi. First off, don't ever, ever, ever post passwords! >:(

    Having gotten past the obligatory chastising i will now assume that you would like to see some kind of Object Oriented example of the code you have provided. Would you settle for a discussion instead?

    First off, OO has been available to Perl since version 5, and yes, you do need modules/packages to define Objects.

    Second, what is 'Objects::MySQL'? There is no CPAN module by that name (nor any namespace for 'Objects'), so (again, assuming because i have not seen the post in question) i would say that the author might have 'hand-rolled' a Database wrapper class named Objects::MySQL.

    Why would one want to do this? Well, in small scripts i think wrapping DBI into _another_ OO interface tends to be overkill, there is not a lot to gain from it and you still type just as much on the whole. Oh yeah, instead of appending die to each and every DBI method call like you do above, just tell DBI to handle die'ing for you:

    my $dbh = DBI->connect( "DBI:mysql:$dbname",$login,$password, { RaiseError => 1 }, ); my $sth = $dbh->prepare('SELECT * FROM catalog'); $sth-> execute();
    But again, why would one want to wrap DBI? Abstraction is one good reason. There is a concept called N-Tier which describes how to design component based, scalable applications. If you want to find out more, just search the web - but try to avoid the marketing whatis.com has a good starting point with 3-tier application.

    Ease is another reason. DBIx::XML_RDB and DBIx::XHTML_Table are two CPAN modules that wrap DBI into another OO interface to provide a user with a way to return the DBI results transformed 'behind the scenes' into XML or an XHTML table respectively (and yes, this reason is really just abstraction in disguise). Both modules accept the database connect info and a SQL statement, but they do not require (or even allow) the user to fetch the rows. Instead, one string containing all the data is returned, wrapped in XML or table tags.

    jeffa

    L-LL-L--L-LL-L--L-LL-L--
    -R--R-RR-R--R-RR-R--R-RR
    F--F--F--F--F--F--F--F--
    (the triplet paradiddle)
    
Re: use Objects:: MySQL ?
by Hero Zzyzzx (Curate) on Jan 01, 2002 at 03:51 UTC

    What exactly is your question? I'm unsure what you're asking. . . While this isn't exactly the way I'd do this, it's perfectly reasonable code. . .

    Edit:Oops. My bad. I didn't understand that your title was the question. The google didn't turn up much. . .

    -Any sufficiently advanced technology is
    indistinguishable from doubletalk.

      Was the gentleman in question taking the "Object Oriented" approach to database connectivity (i.e. use Objects: MySQL) ? After reading (part of) Tom's tutorial re: OO-Perl. My guess is he created a package called "Objects" and that MySQL was one of its ?classes? David