[ViewVC] Diff of: cvs/PApp-SQL/SQL.pm

Comparing PApp-SQL/SQL.pm (file contents):
Revision 1.19 by root, Sun Jan 13 06:09:50 2002 UTC vs.
Revision 1.38 by root, Sat Jun 20 21:03:50 2009 UTC

  my $st = sql_exec $DBH, "select ... where a = ?", $a;
  local $DBH = <database handle>;
  my $st = sql_exec \my($bind_a, $bind_b), "select a,b ...";
- my $st = sql_insertid
+ my $id = sql_insertid
              sql_exec "insert into ... values (?, ?)", $v1, $v2;
  my $a = sql_fetch "select a from ...";
  sql_fetch \my($a, $b), "select a,b ...";
- sql_exists "name from table where name like 'a%'"
+ sql_exists "table where name like 'a%'"
     or die "a* required but not existent";
  my $db = new PApp::SQL::Database "", "DBI:mysql:test", "user", "pass";
  local $PApp::SQL::DBH = $db->checked_dbh; # does 'ping'
 =cut
 package PApp::SQL;
+use Carp ();
 use DBI ();
 BEGIN {
    use base qw(Exporter DynaLoader);
-   $VERSION = 0.1241;
+   $VERSION = '1.04';
    @EXPORT = qw(
          sql_exec  sql_fetch  sql_fetchall  sql_exists sql_insertid $sql_exec
          sql_uexec sql_ufetch sql_ufetchall sql_uexists
    );
    @EXPORT_OK = qw(
 our $DBH;       # the default database handle
 our $Database;	# the current SQL::Database object, if applicable
 our %dbcache;
-=head2 GLOBAL VARIABLES
+=head2 Global Variables
 =over 4
 =item $sql_exec
 Since the C<sql_exec> family of functions return a statement handle there
-must eb another way to test the return value of the C<execute> call. This
+must be another way to test the return value of the C<execute> call. This
 global variable contains the result of the most recent call to C<execute>
 done by this module.
 =item $PApp::SQL::DBH
 The default database handle used by this module if no C<$DBH> was
-specified as argument and no C<$DBH> is found in the current package. See
+specified as argument. See C<sql_exec> for a discussion.
-C<sql_exec> for a discussion.
 =item $PApp::SQL::Database
 The current default C<PApp::SQL::Database>-object. Future versions might
 automatically fall back on this database and create database handles from
 be nice as a placeholder for the database object that corresponds to
 $PApp::SQL::DBH.
 =back
-=head2 FUNCTIONS
+=head2 Functions
 =over 4
 =item $dbh = connect_cached $id, $dsn, $user, $pass, $flags, $connect
 __LINE__ work fine as well).
 The reason C<$id> is necessary is that you might specify special connect
 arguments or special flags, or you might want to configure your $DBH
 differently than maybe other applications requesting the same database
-connection. If none of this is becessary for your application you can
+connection. If none of this is necessary for your application you can
-leave $id empty (i.e. "").
+leave C<$id> empty (i.e. "").
 If specified, C<$connect> is a callback (e.g. a coderef) that will be
 called each time a new connection is being established, with the new
 C<$dbh> as first argument.
       # then connect anew
       $dbcache{$id} =
          eval { DBI->connect($dsn, $user, $pass, $flags) }
          || eval { DBI->connect($dsn, $user, $pass, $flags) }
-         || die "unable to connect to database $dsn: $DBI::errstr\n";
+         || Carp::croak "unable to connect to database $dsn: $DBI::errstr\n";
       $connect->($dbcache{$id}) if $connect;
    }
    $dbcache{$id};
 }
 statement handle. The command and the statement handle will be cached
 (with the database handle and the sql string as key), so prepare will be
 called only once for each distinct sql call (please keep in mind that the
 returned statement will always be the same, so, if you call C<sql_exec>
 with the same dbh and sql-statement twice (e.g. in a subroutine you
-called), the statement handle for the first call mustn't be used.
+called), the statement handle for the first call mustn't not be in use
+anymore, as the subsequent call will re-use the handle.
 The database handle (the first argument) is optional. If it is missing,
-C<sql_exec> first tries to use the variable C<$DBH> in the current (=
+it tries to use database handle in C<$PApp::SQL::DBH>, which you can set
-calling) package and, if that fails, it tries to use database handle in
+before calling these functions. NOTICE: future and former versions of
-C<$PApp::SQL::DBH>, which you can set before calling these functions.
+PApp::SQL might also look up the global variable C<$DBH> in the callers
+package.
+=begin comment
+If it is missing, C<sql_exec> first tries to use the variable C<$DBH>
+in the current (= calling) package and, if that fails, it tries to use
+database handle in C<$PApp::SQL::DBH>, which you can set before calling
+these functions.
+=end comment
 The actual return value from the C<$sth->execute> call is stored in the
 package-global (and exported) variable C<$sql_exec>.
 If any error occurs C<sql_exec> will throw an exception.
 C<sql_uexec> is similar to C<sql_exec> but upgrades all input arguments to
-utf8 before calling the C<execute> method.
+UTF-8 before calling the C<execute> method.
 Examples:
  # easy one
  my $st = sql_exec "select name, id from table where id = ?", $id;
  my($name, $amount) = sql_fetch "select ...", args...
 ... and it's still quite fast unless you fetch large amounts of data.
 C<sql_ufetch> is similar to C<sql_fetch> but upgrades all input values to
-utf8 and forces all result values to utf8.
+UTF-8 and forces all result values to UTF-8 (this does I<not> include result
+parameters, only return values. Using bind variables in conjunction with
+sql_u* functions might result in undefined behaviour - we use UTF-8 on
+bind-variables at execution time and it seems to work on DBD::mysql as it
+ignores the UTF-8 bit completely. Which just means that that DBD-driver is
+broken).
 =item sql_fetchall <see sql_exec>
 =item sql_ufetchall <see sql_uexec>
  for (sql_fetchall "select name, age, place from user") {
     my ($name, $age, $place) = @$_;
  }
 C<sql_ufetchall> is similar to C<sql_fetchall> but upgrades all input
-values to utf8 and forces all result values to utf8.
+values to UTF-8 and forces all result values to UTF-8 (see the caveats in
+the description of C<sql_ufetch>, though).
-=item sql_exists "<table> where ...", args...
+=item sql_exists "<table_references> where <where_condition>...", args...
 =item sql_uexists <see sql_exists>
 Check wether the result of the sql-statement "select xxx from
 $first_argument" would be empty or not (that is, imagine the string
 "select * from" were prepended to your statement (it isn't)). Should work
 with every database but can be quite slow, except on mysql, where this
 should be quite fast.
 C<sql_uexists> is similar to C<sql_exists> but upgrades all parameters to
-utf8.
+UTF-8.
 Examples:
  print "user 7 exists!\n"
     if sql_exists "user where id = ?", 7;
  mysql:    first C<AUTO_INCREMENT> column set to NULL
  postgres: C<oid> column (is there a way to get the last SERIAL?)
  sybase:   C<IDENTITY> column of the last insert (slow)
  informix: C<SERIAL> or C<SERIAL8> column of the last insert
+ sqlite:   C<last_insert_rowid()>
 Except for sybase, this does not require a server access.
 =cut
 sub sql_insertid($) {
-   my $sth = shift or die "sql_insertid requires a statement handle";
+   my $sth = shift or Carp::croak "sql_insertid requires a statement handle";
    my $dbh = $sth->{Database};
    my $driver = $dbh->{Driver}{Name};
    $driver eq "mysql"    and return $sth->{mysql_insertid};
    $driver eq "Pg"       and return $sth->{pg_oid_status};
-   $driver eq "Sybase"   and return sql_fetch($dbh, 'SELECT @@IDENTITY');
+   $driver eq "Sybase"   and return sql_fetch ($dbh, 'SELECT @@IDENTITY');
    $driver eq "Informix" and return $sth->{ix_sqlerrd}[1];
+   $driver eq "SQLite"   and return sql_fetch ($dbh, 'SELECT last_insert_rowid ()');
-   die "sql_insertid does not spport the dbd driver '$driver', please see PApp::SQL::sql_insertid";
+   Carp::croak "sql_insertid does not support the dbd driver '$driver', at";
 }
 =item [old-size] = cachesize [new-size]
 Returns (and possibly changes) the LRU cache size used by C<sql_exec>. The
 default is somewhere around 50 (= the 50 last recently used statements
-will be cached). It shouldn't be too large, since a simple linear listed
+will be cached). It shouldn't be too large, since a simple linear list
 is used for the cache at the moment (which, for small (<100) cache sizes
 is actually quite fast).
 The function always returns the cache size in effect I<before> the call,
 so, to nuke the cache (for example, when a database connection has died
 reinitialize;
 package PApp::SQL::Database;
-=head2 THE DATABASE CLASS
+=head2 The Database Class
 Again (sigh) the problem of persistency. What do you do when you have
 to serialize on object that contains (or should contain) a database
 handle? Short answer: you don't. Long answer: you can embed the necessary
 information to recreate the dbh when needed.
 sub checked_dbh($) {
    my $dbh = $dbcache{$_[0][0]};
    $dbh && $dbh->ping
       ? $dbh
-      : PApp::SQL::connect_cached((split /\x00/, $_[0][0]), $_[0][1], $_[0][2]);
+      : PApp::SQL::connect_cached((split /\x00/, $_[0][0], 4), $_[0][1], $_[0][2]);
 }
 =item $db->dsn
 Return the DSN (L<DBI>) fo the database object (e.g. for error messages).
 Return the login name.
 =item $db->password
-Return the password (emphasizing the fact that the apssword is stored plaintext ;)
+Return the password (emphasizing the fact that the password is stored plaintext ;)
 =cut
 sub dsn($) {
    my $self = shift;
 L<PApp>.
 =head1 AUTHOR
- Marc Lehmann <pcg@goof.com>
+ Marc Lehmann <schmorp@schmorp.de>
- http://www.goof.com/pcg/marc/
+ http://home.schmorp.de/
 =cut

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing PApp-SQL/SQL.pm (file contents): Revision 1.19 by root, Sun Jan 13 06:09:50 2002 UTC vs. Revision 1.38 by root, Sat Jun 20 21:03:50 2009 UTC

Diff Legend

Comparing PApp-SQL/SQL.pm (file contents):
Revision 1.19 by root, Sun Jan 13 06:09:50 2002 UTC vs.
Revision 1.38 by root, Sat Jun 20 21:03:50 2009 UTC