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

Comparing PApp-SQL/SQL.pm (file contents):
Revision 1.23 by root, Sun Apr 7 16:23:56 2002 UTC vs.
Revision 1.32 by root, Thu Sep 1 08:57:28 2005 UTC

 use DBI ();
 BEGIN {
    use base qw(Exporter DynaLoader);
-   $VERSION = 0.13;
+   $VERSION = 1.0;
    @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
 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
 with the same dbh and sql-statement twice (e.g. in a subroutine you
 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 (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;
 =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.
 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.23 by root, Sun Apr 7 16:23:56 2002 UTC vs. Revision 1.32 by root, Thu Sep 1 08:57:28 2005 UTC

Diff Legend

Comparing PApp-SQL/SQL.pm (file contents):
Revision 1.23 by root, Sun Apr 7 16:23:56 2002 UTC vs.
Revision 1.32 by root, Thu Sep 1 08:57:28 2005 UTC