Re: Editing data extracted from mysql through CGI/mod

Great suggestions. I was trying to be pedantic with RaiseError and "..or die" there. Probably cut and paste all over the place trying to track down the source of the problem.

You mentioned using a more generalized conneciton method, which makes sense, however.. how do I pass artguments between subs, yet retain their ability to stay local? In the example above, you mentioned using:

my ($dbh, $article_id) = @_;

..except I'll never know which arguments are passed to $dbh each time. Somtimes it may be one argument, sometimes 20 arguments, so I'll have to construct that inside the sub (not global), after I know the arguments that are going to be passed, right? In this case, that means I have to recreate that handle in each sub where it's used.

Herein lies one part of the equation I'm not familiar with; passing locals between subs as arguments, but never knowing how many arguments will be passed beforehand.

Comment on Re: Editing data extracted from mysql through CGI/mod_perl Download Code

Replies are listed 'Best First'.
Re: Re: Editing data extracted from mysql through CGI/mod_perl by Arguile (Hermit) on Jun 10, 2002 at 21:07 UTC
`$dbh = DBI->connect('conn_str', 'user', 'pass', { <args> });` [download] `$dbh` is just a handle. It simply refers to the connection we just made to the database. As such, you can pass it anywhere and it will always represent that connection to the database. When we say `my $sth = $dbh->prepare('SQL');` we're saying; use this database connection, prepare this SQL code, and return a reference to that code object. It doesn't matter what the SQL is or how many arguments you pass in `$sth->execute()`, as we're still using the same connection. You can `$sth->finish()` that statement and start another on the same `$dbh` because, as stated above, we're still using that same connection. No matter where you pass it or what methods you call on it (excluding `disconnect` of course :) it's still the same connection. If there's a case where you use different logins or connection strings, that's when you'd need to pass a different handle. With our hypothetical generalised connection method in our application modules, we'd pass which type of connection we wanted returned. A standard approach is to make a read only user for most use and other users with varying write permissions (when you still want connection pooling). If you don't get that last bit, don't sweat it. Keep it simple until you've got the basics of DBI down. Also you might want to check out Programming the Perl DBI. If you like your books online http://safari.oreilly.com has all their titles at really great subscription prices. BTW, not trying to be heavy handed or anything. My HS english teacher just said repeating in threes is a good literary device ;)	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: Editing data extracted from mysql through CGI/mod_perl
by Arguile (Hermit) on Jun 10, 2002 at 21:07 UTC

$dbh = DBI->connect('conn_str', 'user', 'pass', { <args> });
[download]

$dbh is just a handle. It simply refers to the connection we just made to the database. As such, you can pass it anywhere and it will always represent that connection to the database. When we say my $sth = $dbh->prepare('SQL'); we're saying; use this database connection, prepare this SQL code, and return a reference to that code object. It doesn't matter what the SQL is or how many arguments you pass in $sth->execute(), as we're still using the same connection. You can $sth->finish() that statement and start another on the same $dbh because, as stated above, we're still using that same connection. No matter where you pass it or what methods you call on it (excluding disconnect of course :) it's still the same connection.

If there's a case where you use different logins or connection strings, that's when you'd need to pass a different handle. With our hypothetical generalised connection method in our application modules, we'd pass which type of connection we wanted returned. A standard approach is to make a read only user for most use and other users with varying write permissions (when you still want connection pooling).

If you don't get that last bit, don't sweat it. Keep it simple until you've got the basics of DBI down. Also you might want to check out Programming the Perl DBI. If you like your books online http://safari.oreilly.com has all their titles at really great subscription prices.

BTW, not trying to be heavy handed or anything. My HS english teacher just said repeating in threes is a good literary device ;)

[reply]
[d/l]
[select]