PApp-SQL/SQL.pm

=head1 NAME

PApp::SQL - absolutely easy yet fast and powerful sql access.

=head1 SYNOPSIS

 use PApp::SQL;

 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 $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 "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'

 sql_exec $db->dbh, "select ...";

=head1 DESCRIPTION

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+. 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 ;)

=cut

package PApp::SQL;

use Carp ();
use DBI ();

BEGIN {
   use base qw(Exporter DynaLoader);

   $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(
         connect_cached
   );

   bootstrap PApp::SQL $VERSION;
}

our $sql_exec;  # last result of sql_exec's execute call
our $DBH;       # the default database handle
our $Database;  # the current SQL::Database object, if applicable

our %dbcache;

=head2 Global Variables

=over 4

=item $sql_exec

Since the C<sql_exec> family of functions return a statement handle there
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. See 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
it if neccessary. At the moment this is not used by this module but might
be nice as a placeholder for the database object that corresponds to
$PApp::SQL::DBH.

=back

=head2 Functions

=over 4

=item $dbh = connect_cached $id, $dsn, $user, $pass, $flags, $connect

(not exported by by default)

Connect to the database given by C<($dsn,$user,$pass)>, while using the
flags from C<$flags>. These are just the same arguments as given to
C<DBI->connect>.

The database handle will be cached under the unique id
C<$id|$dsn|$user|$pass>. If the same id is requested later, the
cached handle will be checked (using ping), and the connection will
be re-established if necessary (be sure to prefix your application or
module name to the id to make it "more" unique. Things like __PACKAGE__ .
__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 necessary for your application you can
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) {
      # 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) }
         || Carp::croak "unable to connect to database $dsn: $DBI::errstr\n";
      $connect->($dbcache{$id}) if $connect;
   }
   $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
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 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,
it tries to use database handle in C<$PApp::SQL::DBH>, which you can set
before calling these functions. NOTICE: future and former versions of
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
UTF-8 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) { ... };

 # the fastest way to use dbi, using bind_columns
 my $st = sql_exec \my($name, $id),
                   "select name, id from table where id = ?",
                   $id;
 while ($st->fetch) { ...}

 # now use a different dastabase:
 sql_exec $dbh, "update file set name = ?", "oops.txt";


=item sql_fetch <see sql_exec>

=item sql_ufetch <see sql_uexec>

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           ()
 scalar         first column
 list           array

C<sql_fetch> is quite efficient in conjunction with bind variables:

 sql_fetch \my($name, $amount),
           "select name, amount from table where id name  = ?",
           "Toytest";

But of course the normal way to call it is simply:

 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
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>

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:

 COLUMNS        RESULT
 0              ()
 1              (row1, row2, row3...)
 many           ([row1], [row2], [row3]...)

Examples (all of which are inefficient):

 for (sql_fetchall "select id from table") { ... }

 my @names = sql_fetchall "select name from user";

 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 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>

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
UTF-8.

Examples:

 print "user 7 exists!\n"
    if sql_exists "user where id = ?", 7;
 
 die "duplicate key"
    if sql_exists "user where name = ? and pass = ?", "stefan", "geheim";

=cut

=item $lastid = sql_insertid $sth

Returns the last automatically created key value. It must be executed
directly after executing the insert statement that created it. This is
what is actually returned for various databases. If your database is
missing, please send me an e-mail on how to implement this ;)

 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 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 "Informix" and return $sth->{ix_sqlerrd}[1];
   $driver eq "SQLite"   and return sql_fetch ($dbh, 'SELECT last_insert_rowid ()');

   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 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
or you want to garbage collect old database/statement handles), this
construct can be used:

 PApp::SQL::cachesize PApp::SQL::cachesize 0;

=cut

=item reinitialize [not exported]

Clears any internal caches (statement cache, database handle
cache). Should be called after C<fork> and other accidents that invalidate
database handles.

=cut

sub reinitialize {
   cachesize cachesize 0;
   for (values %dbcache) {
      eval { $_->{InactiveDestroy} = 1 };
   }
   undef %dbcache;
}

=back

=cut

reinitialize;

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 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.

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).

=over 4

=item $db = new <same arguments as C<connect_cached>>

The C<new> call takes the same arguments as C<connect_cached> (obviously,
if you supply a connect callback it better is serializable, see
L<PApp::Callback>!) and returns a serializable database class. No database
handle is actually being created.

=item $db->dbh

Return the database handle as fast as possible (usually just a hash lookup).

=item $db->checked_dbh

Return the database handle, but first check that the database is still
available and re-open the connection if necessary.

=cut

sub new($$;@) {
   my $class = shift;
   my ($id, $dsn, $user, $pass, $flags, $connect) = @_;
   # the following line is duplicated in PApp::SQL::Database::new
   my $id2 = "$id\0$dsn\0$user\0$pass";
   bless [$id2, $flags, $connect], $class;
}

# the following two functions better be fast!
sub dbh($) {
   $dbcache{$_[0][0]} || $_[0]->checked_dbh;
}

sub checked_dbh($) {
   my $dbh = $dbcache{$_[0][0]};
   $dbh && $dbh->ping
      ? $dbh
      : 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).

=item $db->login

Return the login name.

=item $db->password

Return the password (emphasizing the fact that the password 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;

=head1 SEE ALSO

L<PApp>.

=head1 AUTHOR

 Marc Lehmann <schmorp@schmorp.de>
 http://home.schmorp.de/

=cut

Revision:	1.38
Committed:	Sat Jun 20 21:03:50 2009 UTC (14 years, 11 months ago) by root
Branch:	MAIN
CVS Tags:	rel-1_04
Changes since 1.37:	+7 -6 lines
Log Message:	* empty log message *
#	User	Rev	Content
1	root	1.1	=head1 NAME
2
3	root	1.19	PApp::SQL - absolutely easy yet fast and powerful sql access.
4	root	1.1
5			=head1 SYNOPSIS
6
7			use PApp::SQL;
8	root	1.10
9			my $st = sql_exec $DBH, "select ... where a = ?", $a;
10
11			local $DBH = <database handle>;
12			my $st = sql_exec \my($bind_a, $bind_b), "select a,b ...";
13	root	1.37	my $id = sql_insertid
14	root	1.10	sql_exec "insert into ... values (?, ?)", $v1, $v2;
15			my $a = sql_fetch "select a from ...";
16			sql_fetch \my($a, $b), "select a,b ...";
17
18	root	1.20	sql_exists "table where name like 'a%'"
19	root	1.10	or die "a* required but not existent";
20
21			my $db = new PApp::SQL::Database "", "DBI:mysql:test", "user", "pass";
22			local $PApp::SQL::DBH = $db->checked_dbh; # does 'ping'
23
24			sql_exec $db->dbh, "select ...";
25	root	1.1
26			=head1 DESCRIPTION
27
28			This module provides you with easy-to-use functions to execute sql
29			commands (using DBI). Despite being easy to use, they are also quite
30	root	1.10	efficient and allow you to write faster programs in less lines of code. It
31			should work with anything from perl-5.004_01 onwards, but I only support
32	root	1.15	5.005+. UTF8 handling (the C<sql_u*> family of functions) will only be
33			effective with perl version 5.006 and beyond.
34	root	1.10
35			If the descriptions here seem terse or if you always wanted to know
36			what PApp is then have a look at the PApp module which uses this module
37			extensively but also provides you with a lot more gimmicks to play around
38			with to help you create cool applications ;)
39	root	1.1
40			=cut
41
42			package PApp::SQL;
43
44	root	1.38	use Carp ();
45	root	1.10	use DBI ();
46	root	1.1
47			BEGIN {
48	root	1.10	use base qw(Exporter DynaLoader);
49	root	1.1
50	root	1.38	$VERSION = '1.04';
51	root	1.1	@EXPORT = qw(
52	root	1.16	sql_exec sql_fetch sql_fetchall sql_exists sql_insertid $sql_exec
53			sql_uexec sql_ufetch sql_ufetchall sql_uexists
54	root	1.1	);
55			@EXPORT_OK = qw(
56			connect_cached
57			);
58
59	root	1.10	bootstrap PApp::SQL $VERSION;
60	root	1.1	}
61
62			our $sql_exec; # last result of sql_exec's execute call
63			our $DBH; # the default database handle
64	root	1.10	our $Database; # the current SQL::Database object, if applicable
65	root	1.1
66			our %dbcache;
67
68	root	1.32	=head2 Global Variables
69	root	1.10
70			=over 4
71
72			=item $sql_exec
73
74			Since the C<sql_exec> family of functions return a statement handle there
75	root	1.22	must be another way to test the return value of the C<execute> call. This
76	root	1.10	global variable contains the result of the most recent call to C<execute>
77			done by this module.
78
79			=item $PApp::SQL::DBH
80
81			The default database handle used by this module if no C<$DBH> was
82	root	1.24	specified as argument. See C<sql_exec> for a discussion.
83	root	1.10
84			=item $PApp::SQL::Database
85
86			The current default C<PApp::SQL::Database>-object. Future versions might
87			automatically fall back on this database and create database handles from
88			it if neccessary. At the moment this is not used by this module but might
89			be nice as a placeholder for the database object that corresponds to
90			$PApp::SQL::DBH.
91
92			=back
93
94	root	1.32	=head2 Functions
95	root	1.10
96			=over 4
97
98	root	1.1	=item $dbh = connect_cached $id, $dsn, $user, $pass, $flags, $connect
99
100			(not exported by by default)
101
102			Connect to the database given by C<($dsn,$user,$pass)>, while using the
103			flags from C<$flags>. These are just the same arguments as given to
104			C<DBI->connect>.
105
106	root	1.6	The database handle will be cached under the unique id
107			C<$id\|$dsn\|$user\|$pass>. If the same id is requested later, the
108			cached handle will be checked (using ping), and the connection will
109			be re-established if necessary (be sure to prefix your application or
110			module name to the id to make it "more" unique. Things like __PACKAGE__ .
111			__LINE__ work fine as well).
112
113			The reason C<$id> is necessary is that you might specify special connect
114			arguments or special flags, or you might want to configure your $DBH
115			differently than maybe other applications requesting the same database
116	root	1.22	connection. If none of this is necessary for your application you can
117			leave C<$id> empty (i.e. "").
118	root	1.1
119			If specified, C<$connect> is a callback (e.g. a coderef) that will be
120			called each time a new connection is being established, with the new
121			C<$dbh> as first argument.
122
123			Examples:
124
125			# try your luck opening the papp database without access info
126			$dbh = connect_cached __FILE__, "DBI:mysql:papp";
127
128	root	1.19	Mysql-specific behaviour: The default setting of
129			C<mysql_client_found_rows> is TRUE, you can overwrite this, though.
130	root	1.18
131	root	1.1	=cut
132
133			sub connect_cached {
134			my ($id, $dsn, $user, $pass, $flags, $connect) = @_;
135			# the following line is duplicated in PApp::SQL::Database::new
136			$id = "$id\0$dsn\0$user\0$pass";
137			unless ($dbcache{$id} && $dbcache{$id}->ping) {
138	root	1.5	# first, nuke our statement cache (sooory ;)
139	root	1.1	cachesize cachesize 0;
140	root	1.18
141			# then make mysql behave more standardly by default
142			$dsn =~ /^[Dd][Bb][Ii]:mysql:/
143			and $dsn !~ /;mysql_client_found_rows/
144			and $dsn .= ";mysql_client_found_rows=1";
145
146	root	1.1	# then connect anew
147			$dbcache{$id} =
148			eval { DBI->connect($dsn, $user, $pass, $flags) }
149			\|\| eval { DBI->connect($dsn, $user, $pass, $flags) }
150	root	1.38	\|\| Carp::croak "unable to connect to database $dsn: $DBI::errstr\n";
151	root	1.1	$connect->($dbcache{$id}) if $connect;
152			}
153			$dbcache{$id};
154			}
155
156			=item $sth = sql_exec [dbh,] [bind-vals...,] "sql-statement", [arguments...]
157
158	root	1.15	=item $sth = sql_uexec <see sql_exec>
159
160	root	1.1	C<sql_exec> is the most important and most-used function in this module.
161
162			Runs the given sql command with the given parameters and returns the
163			statement handle. The command and the statement handle will be cached
164			(with the database handle and the sql string as key), so prepare will be
165			called only once for each distinct sql call (please keep in mind that the
166			returned statement will always be the same, so, if you call C<sql_exec>
167			with the same dbh and sql-statement twice (e.g. in a subroutine you
168	root	1.23	called), the statement handle for the first call mustn't not be in use
169			anymore, as the subsequent call will re-use the handle.
170	root	1.1
171			The database handle (the first argument) is optional. If it is missing,
172	root	1.24	it tries to use database handle in C<$PApp::SQL::DBH>, which you can set
173			before calling these functions. NOTICE: future and former versions of
174			PApp::SQL might also look up the global variable C<$DBH> in the callers
175			package.
176
177			=begin comment
178
179			If it is missing, C<sql_exec> first tries to use the variable C<$DBH>
180			in the current (= calling) package and, if that fails, it tries to use
181			database handle in C<$PApp::SQL::DBH>, which you can set before calling
182			these functions.
183
184			=end comment
185	root	1.1
186			The actual return value from the C<$sth->execute> call is stored in the
187			package-global (and exported) variable C<$sql_exec>.
188
189			If any error occurs C<sql_exec> will throw an exception.
190
191	root	1.15	C<sql_uexec> is similar to C<sql_exec> but upgrades all input arguments to
192	root	1.31	UTF-8 before calling the C<execute> method.
193	root	1.15
194	root	1.1	Examples:
195
196			# easy one
197			my $st = sql_exec "select name, id from table where id = ?", $id;
198			while (my ($name, $id) = $st->fetchrow_array) { ... };
199
200			# the fastest way to use dbi, using bind_columns
201			my $st = sql_exec \my($name, $id),
202			"select name, id from table where id = ?",
203			$id;
204			while ($st->fetch) { ...}
205
206			# now use a different dastabase:
207			sql_exec $dbh, "update file set name = ?", "oops.txt";
208
209
210			=item sql_fetch <see sql_exec>
211
212	root	1.15	=item sql_ufetch <see sql_uexec>
213
214			Execute an sql-statement and fetch the first row of results. Depending on
215	root	1.1	the caller context the row will be returned as a list (array context), or
216			just the first columns. In table form:
217
218			CONTEXT RESULT
219			void ()
220			scalar first column
221			list array
222
223			C<sql_fetch> is quite efficient in conjunction with bind variables:
224
225			sql_fetch \my($name, $amount),
226			"select name, amount from table where id name = ?",
227			"Toytest";
228
229			But of course the normal way to call it is simply:
230
231			my($name, $amount) = sql_fetch "select ...", args...
232
233			... and it's still quite fast unless you fetch large amounts of data.
234
235	root	1.15	C<sql_ufetch> is similar to C<sql_fetch> but upgrades all input values to
236	root	1.31	UTF-8 and forces all result values to UTF-8 (this does I<not> include result
237			parameters, only return values. Using bind variables in conjunction with
238			sql_u* functions might result in undefined behaviour - we use UTF-8 on
239			bind-variables at execution time and it seems to work on DBD::mysql as it
240			ignores the UTF-8 bit completely. Which just means that that DBD-driver is
241			broken).
242	root	1.15
243	root	1.1	=item sql_fetchall <see sql_exec>
244
245	root	1.15	=item sql_ufetchall <see sql_uexec>
246
247	root	1.1	Similarly to C<sql_fetch>, but all result rows will be fetched (this is
248			of course inefficient for large results!). The context is ignored (only
249			list context makes sense), but the result still depends on the number of
250			columns in the result:
251
252			COLUMNS RESULT
253			0 ()
254			1 (row1, row2, row3...)
255			many ([row1], [row2], [row3]...)
256
257			Examples (all of which are inefficient):
258
259			for (sql_fetchall "select id from table") { ... }
260
261			my @names = sql_fetchall "select name from user";
262
263			for (sql_fetchall "select name, age, place from user") {
264			my ($name, $age, $place) = @$_;
265			}
266
267	root	1.15	C<sql_ufetchall> is similar to C<sql_fetchall> but upgrades all input
268	root	1.31	values to UTF-8 and forces all result values to UTF-8 (see the caveats in
269	root	1.21	the description of C<sql_ufetch>, though).
270	root	1.15
271	root	1.20	=item sql_exists "<table_references> where <where_condition>...", args...
272	root	1.1
273	root	1.15	=item sql_uexists <see sql_exists>
274
275	root	1.1	Check wether the result of the sql-statement "select xxx from
276			$first_argument" would be empty or not (that is, imagine the string
277	root	1.13	"select * from" were prepended to your statement (it isn't)). Should work
278	root	1.1	with every database but can be quite slow, except on mysql, where this
279			should be quite fast.
280
281	root	1.15	C<sql_uexists> is similar to C<sql_exists> but upgrades all parameters to
282	root	1.31	UTF-8.
283	root	1.15
284	root	1.1	Examples:
285
286			print "user 7 exists!\n"
287			if sql_exists "user where id = ?", 7;
288
289			die "duplicate key"
290			if sql_exists "user where name = ? and pass = ?", "stefan", "geheim";
291
292			=cut
293
294	root	1.3	=item $lastid = sql_insertid $sth
295
296	root	1.8	Returns the last automatically created key value. It must be executed
297			directly after executing the insert statement that created it. This is
298			what is actually returned for various databases. If your database is
299			missing, please send me an e-mail on how to implement this ;)
300
301			mysql: first C<AUTO_INCREMENT> column set to NULL
302			postgres: C<oid> column (is there a way to get the last SERIAL?)
303			sybase: C<IDENTITY> column of the last insert (slow)
304			informix: C<SERIAL> or C<SERIAL8> column of the last insert
305	root	1.34	sqlite: C<last_insert_rowid()>
306	root	1.8
307			Except for sybase, this does not require a server access.
308	root	1.3
309			=cut
310
311			sub sql_insertid($) {
312	root	1.38	my $sth = shift or Carp::croak "sql_insertid requires a statement handle";
313	root	1.3	my $dbh = $sth->{Database};
314			my $driver = $dbh->{Driver}{Name};
315
316	root	1.8	$driver eq "mysql" and return $sth->{mysql_insertid};
317			$driver eq "Pg" and return $sth->{pg_oid_status};
318	root	1.38	$driver eq "Sybase" and return sql_fetch ($dbh, 'SELECT @@IDENTITY');
319	root	1.3	$driver eq "Informix" and return $sth->{ix_sqlerrd}[1];
320	root	1.38	$driver eq "SQLite" and return sql_fetch ($dbh, 'SELECT last_insert_rowid ()');
321	root	1.3
322	root	1.38	Carp::croak "sql_insertid does not support the dbd driver '$driver', at";
323	root	1.1	}
324
325			=item [old-size] = cachesize [new-size]
326
327			Returns (and possibly changes) the LRU cache size used by C<sql_exec>. The
328			default is somewhere around 50 (= the 50 last recently used statements
329	root	1.26	will be cached). It shouldn't be too large, since a simple linear list
330	root	1.1	is used for the cache at the moment (which, for small (<100) cache sizes
331			is actually quite fast).
332
333			The function always returns the cache size in effect I<before> the call,
334			so, to nuke the cache (for example, when a database connection has died
335			or you want to garbage collect old database/statement handles), this
336			construct can be used:
337
338			PApp::SQL::cachesize PApp::SQL::cachesize 0;
339
340			=cut
341
342			=item reinitialize [not exported]
343
344	root	1.9	Clears any internal caches (statement cache, database handle
345			cache). Should be called after C<fork> and other accidents that invalidate
346			database handles.
347	root	1.1
348			=cut
349
350			sub reinitialize {
351			cachesize cachesize 0;
352			for (values %dbcache) {
353	root	1.11	eval { $_->{InactiveDestroy} = 1 };
354	root	1.1	}
355			undef %dbcache;
356			}
357
358			=back
359
360			=cut
361
362	root	1.7	reinitialize;
363
364	root	1.1	package PApp::SQL::Database;
365
366	root	1.32	=head2 The Database Class
367	root	1.1
368	root	1.15	Again (sigh) the problem of persistency. What do you do when you have
369			to serialize on object that contains (or should contain) a database
370			handle? Short answer: you don't. Long answer: you can embed the necessary
371			information to recreate the dbh when needed.
372	root	1.1
373			The C<PApp::SQL::Database> class does that, in a relatively efficient
374			fashion: the overhead is currently a single method call per access (you
375			can cache the real dbh if you want).
376
377			=over 4
378
379			=item $db = new <same arguments as C<connect_cached>>
380
381			The C<new> call takes the same arguments as C<connect_cached> (obviously,
382			if you supply a connect callback it better is serializable, see
383			L<PApp::Callback>!) and returns a serializable database class. No database
384			handle is actually being created.
385
386			=item $db->dbh
387
388			Return the database handle as fast as possible (usually just a hash lookup).
389
390			=item $db->checked_dbh
391
392			Return the database handle, but first check that the database is still
393			available and re-open the connection if necessary.
394
395			=cut
396
397			sub new($$;@) {
398			my $class = shift;
399			my ($id, $dsn, $user, $pass, $flags, $connect) = @_;
400			# the following line is duplicated in PApp::SQL::Database::new
401			my $id2 = "$id\0$dsn\0$user\0$pass";
402			bless [$id2, $flags, $connect], $class;
403			}
404
405			# the following two functions better be fast!
406			sub dbh($) {
407			$dbcache{$_[0][0]} \|\| $_[0]->checked_dbh;
408			}
409
410			sub checked_dbh($) {
411			my $dbh = $dbcache{$_[0][0]};
412			$dbh && $dbh->ping
413			? $dbh
414	elmex	1.35	: PApp::SQL::connect_cached((split /\x00/, $_[0][0], 4), $_[0][1], $_[0][2]);
415	root	1.1	}
416
417			=item $db->dsn
418
419			Return the DSN (L<DBI>) fo the database object (e.g. for error messages).
420
421	root	1.14	=item $db->login
422
423			Return the login name.
424
425			=item $db->password
426
427	root	1.25	Return the password (emphasizing the fact that the password is stored plaintext ;)
428	root	1.14
429	root	1.1	=cut
430
431			sub dsn($) {
432			my $self = shift;
433	root	1.9	(split /\x00/, $self->[0])[1];
434	root	1.14	}
435
436			sub login($) {
437			my $self = shift;
438			(split /\x00/, $self->[0])[2];
439			}
440
441			sub password($) {
442			my $self = shift;
443			(split /\x00/, $self->[0])[3];
444	root	1.1	}
445
446			=back
447
448			=cut
449
450			1;
451
452			=head1 SEE ALSO
453
454			L<PApp>.
455
456			=head1 AUTHOR
457
458	root	1.32	Marc Lehmann <schmorp@schmorp.de>
459			http://home.schmorp.de/
460	root	1.1
461			=cut
462