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

Comparing PApp-SQL/SQL.pm (file contents):
Revision 1.24 by root, Thu Apr 11 01:02:10 2002 UTC vs.
Revision 1.36 by root, Fri Mar 3 14:12:22 2006 UTC

 use DBI ();
 BEGIN {
    use base qw(Exporter DynaLoader);
-   $VERSION = 0.131;
+   $VERSION = '1.02';
    @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
 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
 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 (this does I<not> include result
+UTF-8 and forces all result values to UTF-8 (this does I<not> include result
-parameters, only return values. Using bind variables in cinjunction with
+parameters, only return values. Using bind variables in conjunction with
-sql_u* functions results in undefined behaviour).
+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 (see the caveats in
+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_references> where <where_condition>...", args...
 =item sql_uexists <see sql_exists>
 "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
    $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 "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";
 }
 =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.24 by root, Thu Apr 11 01:02:10 2002 UTC vs. Revision 1.36 by root, Fri Mar 3 14:12:22 2006 UTC

Diff Legend

Comparing PApp-SQL/SQL.pm (file contents):
Revision 1.24 by root, Thu Apr 11 01:02:10 2002 UTC vs.
Revision 1.36 by root, Fri Mar 3 14:12:22 2006 UTC