Re: DBI article in Korean

Hi,

On Wed, May 22, 2013 at 10:08 PM, Martin J. Evans <[email protected]> wrote:

> Another good tutorial - please keep up the good work of promoting Perl.

Thanks. I hope others will also help promoting my articles and interviews.

> "The DSN (Data Source Name) (in the $dsn variable) is very straight forward.
> It contains the type of the database. That will be the clue to DBI which DBD
> to load. In case of SQLite, the only thing we really need is the path to the
> database file."
>
> It may be a language thing but it is hardly a "clue". DBI clearly states the
> connection string is dbi:DRIVER_NAME:something_else and DRIVER_NAMEs are
> registered with DBI. Its also not always as "straight forward" as you
> suggest as the something_else is usually a ';' separated string of
> attributes and values e.g. "DRIVER={this driver}".

I know it can be more complex than my example, but I don't have to
frighten away the reader :)
I am confused with your comment about the word "clue". Isn't the name
of DBD::* derived from
the DRIVER_NAME ? Or does clue mean something else then guiding information?
Or do you mean that DRIVER_NAME is exact and a "clue" is only a direction?


> "The call to disconnect from the database is optional as it will
> automatically be called when the variable $dbh goes out of scope, but it
> having it might be a clear indication for the next programmer dealing with
> this code, that you are done with the database. "
>
> There are a number of gotchas with this. You may still have a select
> statement active where you've not fetched all the rows yet from the cursor
> in which case you'll get a warning. Also, you may be in the middle of a
> transaction and in that case the transaction may be rolled back.

Are these gotchas different in case $dbh goes out of scope and when I
call $dbh->disconnect ?


> "INSERT"
> "UPDATE"

Clearly, I'll need more articles explaining database handling in more detail.
The thing is, I don't want to overwhelm the readers by giving them
all the examples and explanations at once.


> "This is by far the most interesting part of the database access. As the
> SELECT statement can return a lot of rows and a lot of values in each row we
> cannot use a simple call to the do method. "
>
> Some DBDs really dislike using the do method for select stmts and especially
> multiple stmts in the same SQL e.g., do(q/something; select something from
> something/);

I have not encountered that, but then I don't think I ever used do for
SELECT and
I think I use multiple SQL statements in one dbi call very rarely, if at all.

Surely an article about this could be interesting. I wonder who would
want to write it?
(hint hint :)

regards
  Gabor