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

Comparing PApp-SQL/SQL.pm (file contents):
Revision 1.12 by root, Mon Feb 12 17:47:10 2001 UTC vs.
Revision 1.22 by root, Sun Apr 7 16:22:56 2002 UTC

 =head1 NAME
-PApp::SQL - absolutely easy yet fast and powerful sql access
+PApp::SQL - absolutely easy yet fast and powerful sql access.
 =head1 SYNOPSIS
  use PApp::SQL;
  my $st = 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'
 This module provides you with easy-to-use functions to execute sql
 commands (using DBI). Despite being easy to use, they are also quite
 efficient and allow you to write faster programs in less lines of code. It
 should work with anything from perl-5.004_01 onwards, but I only support
-5.005+.
+5.005+. UTF8 handling (the C<sql_u*> family of functions) will only be
+effective with perl version 5.006 and beyond.
 If the descriptions here seem terse or if you always wanted to know
 what PApp is then have a look at the PApp module which uses this module
 extensively but also provides you with a lot more gimmicks to play around
 with to help you create cool applications ;)
 use DBI ();
 BEGIN {
    use base qw(Exporter DynaLoader);
-   $VERSION = 0.121;
+   $VERSION = 0.13;
    @EXPORT = qw(
-         sql_exec sql_fetch sql_fetchall sql_exists sql_insertid $sql_exec
+         sql_exec  sql_fetch  sql_fetchall  sql_exists sql_insertid $sql_exec
+         sql_uexec sql_ufetch sql_ufetchall sql_uexists
    );
    @EXPORT_OK = qw(
          connect_cached
    );
 =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
 __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.
 Examples:
  # try your luck opening the papp database without access info
  $dbh = connect_cached __FILE__, "DBI:mysql:papp";
+Mysql-specific behaviour: The default setting of
+C<mysql_client_found_rows> is TRUE, you can overwrite this, though.
 =cut
 sub connect_cached {
    my ($id, $dsn, $user, $pass, $flags, $connect) = @_;
    # the following line is duplicated in PApp::SQL::Database::new
    $id = "$id\0$dsn\0$user\0$pass";
    unless ($dbcache{$id} && $dbcache{$id}->ping) {
-      #warn "connecting to ($dsn|$user|$pass|$flags)\n";#d#
       # first, nuke our statement cache (sooory ;)
       cachesize cachesize 0;
+      # then make mysql behave more standardly by default
+      $dsn =~ /^[Dd][Bb][Ii]:mysql:/
+         and $dsn !~ /;mysql_client_found_rows/
+            and $dsn .= ";mysql_client_found_rows=1";
       # 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";
    $dbcache{$id};
 }
 =item $sth = sql_exec [dbh,] [bind-vals...,] "sql-statement", [arguments...]
+=item $sth = sql_uexec <see sql_exec>
 C<sql_exec> is the most important and most-used function in this module.
 Runs the given sql command with the given parameters and returns the
 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
 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.
 Examples:
  # easy one
  my $st = sql_exec "select name, id from table where id = ?", $id;
  while (my ($name, $id) = $st->fetchrow_array) { ... };
  sql_exec $dbh, "update file set name = ?", "oops.txt";
 =item sql_fetch <see sql_exec>
+=item sql_ufetch <see sql_uexec>
-Execute a sql-statement and fetch the first row of results. Depending on
+Execute an sql-statement and fetch the first row of results. Depending on
 the caller context the row will be returned as a list (array context), or
 just the first columns. In table form:
  CONTEXT	RESULT
  void		()
  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 (this does I<not> include result
+parameters, only return values. Using bind variables in cinjunction with
+sql_u* functions results in undefined behaviour).
 =item sql_fetchall <see sql_exec>
+=item sql_ufetchall <see sql_uexec>
 Similarly to C<sql_fetch>, but all result rows will be fetched (this is
 of course inefficient for large results!). The context is ignored (only
 list context makes sense), but the result still depends on the number of
 columns in the result:
  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 (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
+"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.
 Examples:
  print "user 7 exists!\n"
     if sql_exists "user where id = ?", 7;
 package PApp::SQL::Database;
 =head2 THE DATABASE CLASS
-Again (sigh) the problem of persistency. What do you do when you have to serialize on object
+Again (sigh) the problem of persistency. What do you do when you have
-that contains (or should contain) a database handle? Short answer: you don't. Long answer:
+to serialize on object that contains (or should contain) a database
+handle? Short answer: you don't. Long answer: you can embed the necessary
-you can embed the necessary information to recreate the dbh when needed.
+information to recreate the dbh when needed.
 The C<PApp::SQL::Database> class does that, in a relatively efficient
 fashion: the overhead is currently a single method call per access (you
 can cache the real dbh if you want).
 =item $db->dsn
 Return the DSN (L<DBI>) fo the database object (e.g. for error messages).
+=item $db->login
+Return the login name.
+=item $db->password
+Return the password (emphasizing the fact that the apssword is stored plaintext ;)
 =cut
 sub dsn($) {
    my $self = shift;
    (split /\x00/, $self->[0])[1];
 }
+sub login($) {
+   my $self = shift;
+   (split /\x00/, $self->[0])[2];
+}
+sub password($) {
+   my $self = shift;
+   (split /\x00/, $self->[0])[3];
+}
 =back
 =cut
 1;

Diff Legend

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

Comparing PApp-SQL/SQL.pm (file contents): Revision 1.12 by root, Mon Feb 12 17:47:10 2001 UTC vs. Revision 1.22 by root, Sun Apr 7 16:22:56 2002 UTC

Diff Legend

Comparing PApp-SQL/SQL.pm (file contents):
Revision 1.12 by root, Mon Feb 12 17:47:10 2001 UTC vs.
Revision 1.22 by root, Sun Apr 7 16:22:56 2002 UTC