PApp-SQL/SQL.pm

=head1 NAME

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

=head1 SYNOPSIS

 use PApp::SQL;
 # to be written

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

=over 4

=cut

package PApp::SQL;

use DBI;

#use PApp::Exception; # not yet used

BEGIN {
   use base Exporter;

   $VERSION = 0.1;
   @EXPORT = qw(
         sql_exec sql_fetch sql_fetchall sql_exists sql_insertid $sql_exec
   );
   @EXPORT_OK = qw(
         connect_cached
   );

   require XSLoader;
   XSLoader::load 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;

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

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

=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 cache (sooory ;)
      cachesize cachesize 0;
      # then connect anew
      $dbcache{$id} =
         eval { DBI->connect($dsn, $user, $pass, $flags) }
         || eval { DBI->connect($dsn, $user, $pass, $flags) }
         || die "$DBI::errstr\n";
      $connect->($dbcache{$id}) if $connect;
   }
   $dbcache{$id};
}

=item $sth = sql_exec [dbh,] [bind-vals...,] "sql-statement", [arguments...]

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

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

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.

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>

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

=item sql_fetchall <see sql_exec>

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) = @$_;
 }

=item sql_exists "<table> where ...", args...

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.

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

# uncodumented, since unportable (only works with DBH even!). yet it is exported (aaargh!)
sub sql_insertid {
   $DBH->{mysql_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
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).

=cut

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

=back

=cut

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]), $_[0][1], $_[0][2]);
}

=item $db->dsn

Return the DSN (L<DBI>) fo the database object (e.g. for error messages).

=cut

sub dsn($) {
   my $self = shift;
   $self->[1][1];
}

=back

=cut

reinitialize;

1;

=head1 BUGS

As of this writing, sql_fetch and sql_fetchall are not very well tested
(they were just re-written in C).

sql_exists could be faster (it is written very ugly to not change the
current package).

=head1 SEE ALSO

L<PApp>.

=head1 AUTHOR

 Marc Lehmann <pcg@goof.com>
 http://www.goof.com/pcg/marc/

=cut

Revision:	1.2
Committed:	Wed Nov 1 03:22:07 2000 UTC (23 years, 6 months ago) by root
Branch:	MAIN
Changes since 1.1:	+1 -1 lines
Log Message:	* empty log message *
#	User	Rev	Content
1	root	1.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			# to be written
9
10			=head1 DESCRIPTION
11
12			This module provides you with easy-to-use functions to execute sql
13			commands (using DBI). Despite being easy to use, they are also quite
14			efficient and allow you to write faster programs in less lines of code.
15
16			=over 4
17
18			=cut
19
20			package PApp::SQL;
21
22			use DBI;
23
24			#use PApp::Exception; # not yet used
25
26			BEGIN {
27			use base Exporter;
28
29			$VERSION = 0.1;
30			@EXPORT = qw(
31			sql_exec sql_fetch sql_fetchall sql_exists sql_insertid $sql_exec
32			);
33			@EXPORT_OK = qw(
34			connect_cached
35			);
36
37			require XSLoader;
38			XSLoader::load PApp::SQL, $VERSION;
39			}
40
41			our $sql_exec; # last result of sql_exec's execute call
42			our $DBH; # the default database handle
43			our $database; # the current SQL::Database object, if applicable
44
45			our %dbcache;
46
47			=item $dbh = connect_cached $id, $dsn, $user, $pass, $flags, $connect
48
49			(not exported by by default)
50
51			Connect to the database given by C<($dsn,$user,$pass)>, while using the
52			flags from C<$flags>. These are just the same arguments as given to
53			C<DBI->connect>.
54
55			The database handle will be cached under the unique id C<$id>. If the same
56			id is requested later, the cached handle will be checked (using ping), and
57			the connection will be re-established if necessary (be sure to prefix your
58			application or module name to the id to make it "more" unique. Things like
59			__PACKAGE__ . __LINE__ work fine as well).
60
61			If specified, C<$connect> is a callback (e.g. a coderef) that will be
62			called each time a new connection is being established, with the new
63			C<$dbh> as first argument.
64
65			Examples:
66
67			# try your luck opening the papp database without access info
68			$dbh = connect_cached __FILE__, "DBI:mysql:papp";
69
70			=cut
71
72			sub connect_cached {
73			my ($id, $dsn, $user, $pass, $flags, $connect) = @_;
74			# the following line is duplicated in PApp::SQL::Database::new
75			$id = "$id\0$dsn\0$user\0$pass";
76			unless ($dbcache{$id} && $dbcache{$id}->ping) {
77			#warn "connecting to ($dsn\|$user\|$pass\|$flags)\n";#d#
78			# first, nuke our cache (sooory ;)
79			cachesize cachesize 0;
80			# then connect anew
81			$dbcache{$id} =
82			eval { DBI->connect($dsn, $user, $pass, $flags) }
83			\|\| eval { DBI->connect($dsn, $user, $pass, $flags) }
84	root	1.2	\|\| die "$DBI::errstr\n";
85	root	1.1	$connect->($dbcache{$id}) if $connect;
86			}
87			$dbcache{$id};
88			}
89
90			=item $sth = sql_exec [dbh,] [bind-vals...,] "sql-statement", [arguments...]
91
92			C<sql_exec> is the most important and most-used function in this module.
93
94			Runs the given sql command with the given parameters and returns the
95			statement handle. The command and the statement handle will be cached
96			(with the database handle and the sql string as key), so prepare will be
97			called only once for each distinct sql call (please keep in mind that the
98			returned statement will always be the same, so, if you call C<sql_exec>
99			with the same dbh and sql-statement twice (e.g. in a subroutine you
100			called), the statement handle for the first call mustn't be used.
101
102			The database handle (the first argument) is optional. If it is missing,
103			C<sql_exec> first tries to use the variable C<$DBH> in the current (=
104			calling) package and, if that fails, it tries to use database handle in
105			C<$PApp::SQL::DBH>, which you can set before calling these functions.
106
107			The actual return value from the C<$sth->execute> call is stored in the
108			package-global (and exported) variable C<$sql_exec>.
109
110			If any error occurs C<sql_exec> will throw an exception.
111
112			Examples:
113
114			# easy one
115			my $st = sql_exec "select name, id from table where id = ?", $id;
116			while (my ($name, $id) = $st->fetchrow_array) { ... };
117
118			# the fastest way to use dbi, using bind_columns
119			my $st = sql_exec \my($name, $id),
120			"select name, id from table where id = ?",
121			$id;
122			while ($st->fetch) { ...}
123
124			# now use a different dastabase:
125			sql_exec $dbh, "update file set name = ?", "oops.txt";
126
127
128			=item sql_fetch <see sql_exec>
129
130			Execute a sql-statement and fetch the first row of results. Depending on
131			the caller context the row will be returned as a list (array context), or
132			just the first columns. In table form:
133
134			CONTEXT RESULT
135			void ()
136			scalar first column
137			list array
138
139			C<sql_fetch> is quite efficient in conjunction with bind variables:
140
141			sql_fetch \my($name, $amount),
142			"select name, amount from table where id name = ?",
143			"Toytest";
144
145			But of course the normal way to call it is simply:
146
147			my($name, $amount) = sql_fetch "select ...", args...
148
149			... and it's still quite fast unless you fetch large amounts of data.
150
151			=item sql_fetchall <see sql_exec>
152
153			Similarly to C<sql_fetch>, but all result rows will be fetched (this is
154			of course inefficient for large results!). The context is ignored (only
155			list context makes sense), but the result still depends on the number of
156			columns in the result:
157
158			COLUMNS RESULT
159			0 ()
160			1 (row1, row2, row3...)
161			many ([row1], [row2], [row3]...)
162
163			Examples (all of which are inefficient):
164
165			for (sql_fetchall "select id from table") { ... }
166
167			my @names = sql_fetchall "select name from user";
168
169			for (sql_fetchall "select name, age, place from user") {
170			my ($name, $age, $place) = @$_;
171			}
172
173			=item sql_exists "<table> where ...", args...
174
175			Check wether the result of the sql-statement "select xxx from
176			$first_argument" would be empty or not (that is, imagine the string
177			"select from" were prepended to your statement (it isn't)). Should work
178			with every database but can be quite slow, except on mysql, where this
179			should be quite fast.
180
181			Examples:
182
183			print "user 7 exists!\n"
184			if sql_exists "user where id = ?", 7;
185
186			die "duplicate key"
187			if sql_exists "user where name = ? and pass = ?", "stefan", "geheim";
188
189			=cut
190
191			# uncodumented, since unportable (only works with DBH even!). yet it is exported (aaargh!)
192			sub sql_insertid {
193			$DBH->{mysql_insertid};
194			}
195
196			=item [old-size] = cachesize [new-size]
197
198			Returns (and possibly changes) the LRU cache size used by C<sql_exec>. The
199			default is somewhere around 50 (= the 50 last recently used statements
200			will be cached). It shouldn't be too large, since a simple linear listed
201			is used for the cache at the moment (which, for small (<100) cache sizes
202			is actually quite fast).
203
204			The function always returns the cache size in effect I<before> the call,
205			so, to nuke the cache (for example, when a database connection has died
206			or you want to garbage collect old database/statement handles), this
207			construct can be used:
208
209			PApp::SQL::cachesize PApp::SQL::cachesize 0;
210
211			=cut
212
213			=item reinitialize [not exported]
214
215			Clears any internal caches (statement cache, database handle cache).
216
217			=cut
218
219			sub reinitialize {
220			cachesize cachesize 0;
221			for (values %dbcache) {
222			eval { $_->disconnect };
223			}
224			undef %dbcache;
225			}
226
227			=back
228
229			=cut
230
231			package PApp::SQL::Database;
232
233			=head2 THE DATABASE CLASS
234
235			Again (sigh) the problem of persistency. What do you do when you have to serialize on object
236			that contains (or should contain) a database handle? Short answer: you don't. Long answer:
237			you can embed the necessary information to recreate the dbh when needed.
238
239			The C<PApp::SQL::Database> class does that, in a relatively efficient
240			fashion: the overhead is currently a single method call per access (you
241			can cache the real dbh if you want).
242
243			=over 4
244
245			=item $db = new <same arguments as C<connect_cached>>
246
247			The C<new> call takes the same arguments as C<connect_cached> (obviously,
248			if you supply a connect callback it better is serializable, see
249			L<PApp::Callback>!) and returns a serializable database class. No database
250			handle is actually being created.
251
252			=item $db->dbh
253
254			Return the database handle as fast as possible (usually just a hash lookup).
255
256			=item $db->checked_dbh
257
258			Return the database handle, but first check that the database is still
259			available and re-open the connection if necessary.
260
261			=cut
262
263			sub new($$;@) {
264			my $class = shift;
265			my ($id, $dsn, $user, $pass, $flags, $connect) = @_;
266			# the following line is duplicated in PApp::SQL::Database::new
267			my $id2 = "$id\0$dsn\0$user\0$pass";
268			bless [$id2, $flags, $connect], $class;
269			}
270
271			# the following two functions better be fast!
272			sub dbh($) {
273			$dbcache{$_[0][0]} \|\| $_[0]->checked_dbh;
274			}
275
276			sub checked_dbh($) {
277			my $dbh = $dbcache{$_[0][0]};
278			$dbh && $dbh->ping
279			? $dbh
280			: PApp::SQL::connect_cached((split /\x00/, $_[0][0]), $_[0][1], $_[0][2]);
281			}
282
283			=item $db->dsn
284
285			Return the DSN (L<DBI>) fo the database object (e.g. for error messages).
286
287			=cut
288
289			sub dsn($) {
290			my $self = shift;
291			$self->[1][1];
292			}
293
294			=back
295
296			=cut
297
298			reinitialize;
299
300			1;
301
302			=head1 BUGS
303
304			As of this writing, sql_fetch and sql_fetchall are not very well tested
305			(they were just re-written in C).
306
307			sql_exists could be faster (it is written very ugly to not change the
308			current package).
309
310			=head1 SEE ALSO
311
312			L<PApp>.
313
314			=head1 AUTHOR
315
316			Marc Lehmann <pcg@goof.com>
317			http://www.goof.com/pcg/marc/
318
319			=cut
320