home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam  

Book HomeJava and XSLTSearch this book

12.2. Design of DBI

If DBM is too primitive for your database requirements, you'll have to use a more sophisticated database package. Options include the commercial products Oracle, Sybase, and Informix, and the freely available MySQL and Postgres.

Prior to Perl Version 5 and DBI, the problem was that with all the database packages to choose from, there was no way to universalize database support for Perl. You'd have to rebuild the Perl executable itself against libraries that included subroutines for direct access to the database package. For example, sybperl and oraperl are both packages for building Perl Version 4 with Sybase and Oracle calls embedded, respectively. An application written for sybperl would not be portable to Oracle, or vice versa. However, since current versions of Perl support binary extension loading at runtime, database support can now be added at runtime, which simplifies adding database interfaces to Perl programs while keeping the size of the Perl binary to a minimum.

Support for binary extensions doesn't mean that database access has been standardized. There are still many database extensions to Perl, each with a different API. However, their underlying support for SQL (or ability to be manipulated into a form that mimics the behavior of SQL through a DBD) has made it possible to develop a standard set of methods to work with any database. DBI defines a set of functions, variables, and conventions that provide a consistent database programming interface for Perl.

12.2.2. Creating a Database

Before you can open a connection to a database with DBI, you must create the database. DBI can't do this step for you, although your DBD might allow you to. For example, DBD::MySQL implements a _CreateDB function. Your DBD might also support the func method, which is used to call private (and often nonportable) methods in the driver. You could use a one-liner like this to create the database from the command line:

perl -MDBI -e '$db_name = q[database_name_here]; \
     $result = DBD::mysql::dr->func($db_name, '_CreateDB');'

If your DBD allows to you to create databases via the API, it's likely that it will allow you to drop them, too:

perl -MDBI -e '$db_name = q[database_name_here]; \
    $result = DBD::mysql::dr->func($db_name, '_DropDB');'

12.2.3. Database Handles and Statement Handles

DBI methods work on two different types of handles: database handles and statement handles. A database handle is like a filehandle; connect is a DBI class method that opens a connection to a database and returns a database handle object:

$db_handle = DBI->connect(dbi:mSQL:bookdb, undef, undef)
    || die("Connect error: $DBI::errstr");

Statement handles are another thing entirely. DBI makes a distinction between the preparation of SQL statements and their execution by allowing you to preformat a statement into a statement handle. You can prepare a statement with the prepare method, which returns a statement handle. You can then assign a SQL statement to the statement handle via various statement handle methods and execute it with the execute method when you're done. (You can also prepare and execute in the same command with the do method.)

Changes to the database are written to the database automatically if the AutoCommit attribute is turned on. If AutoCommit is off, use the commit method when you're ready to write the changes to the database.

AutoCommit is only one of many attributes that can be set for both database and statement handles. For example, if $st_handle is a statement handle, you can set $st_handle->{NULLABLE} to determine if the fields can contain null characters. Table 12-2 is a listing of all the attributes supported by database handles, statement handles, or both.

Table 12-2. Attributes for database and statement handles



Attribute for database handles


Commits any changes to the database immediately, instead of waiting for an explicit call to commit. Default is true.

Attributes for statement handles


The name of the cursor associated with the statement handle.


A reference to an array of field names.


A reference to an array describing whether each field can contain a null character.


Number of fields the prepared statement will return.


Number of placeholders in the prepared statement.

Attributes common to all handles


Enables warnings.


Enables compatible behavior for a specific driver.


Destroying a handle does not close prepared statements or disconnect from the database.


Errors generate warnings.


Errors raise exceptions.


Truncates trailing space characters in fixed-width character fields.


Controls the maximum length of long data.


Controls whether fetching long data that has been truncated should fail.

Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.