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

BEGIN {
   use base qw(Exporter DynaLoader);

   $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(
         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) }
         || die "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 die "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 ()');

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