Re: Re: DBI recipes

[gmax]

in reply to Re: DBI recipes
in thread DBI recipes

Thanks for the Sybase syntax.

There's no execuse to not wrap your database modifying statements inside a transaction, and to not rollback on failure.

Nonetheless, I'll give you some.

I had error checking and transaction support in my test script, but I removed them on purpose.

Why?

• This post is focused on idioms, and I didn't want to burden the examples with something that doesn't belong there.
• Error checking is an idiom in itself. You can check for errors by testing the object, by creating a handle sub, by using eval. Depending on your needs, the error checking could take several shapes, and I have approached this subject elsewhere.
• Transactions are not a mandatory DBI feature. The DBI can deal with the big boys (Oracle, MS SQL, IBM DB2, and so on) but it can also handle DBF files, Excel spreadsheets, CSV files, and others where transactions are not supported.
• When transactions are supported, while it is true that every update BELONGS TO a transaction, it is not true that every update IS a transaction (Update meaning that the transaction-related code could be around a group of statements rather than around a single one.) So, in addition to my goal of keeping the code focused on the example, I didn't want to give the impression that the transaction code is necessary for that particular idiom to work.

 _  _ _  _  
(_|| | |(_|><
 _|   

[mpeppler]

When transactions are supported, while it is true that every update BELONGS TO a transaction, it is not true that every insertion IS a transaction.

I'm nitpicking, but with Oracle, DB2, Sybase, etc. every DML operation is run in a transaction. The transaction may automatically commit at the end of the operation (i.e. if AutoCommit is on), but there is always at least an implicit transaction as even a single row insert may in fact generate more operations through triggers (inserts to a shadow table, updates of summary tables, etc.) and these all will be guaranteed to perform as a single operation, even in the absence of explicit transactions in the DML.

That being said I think that keeping the transaction logic out of the examples is a good thing, as long as their use and functionality is explained somewhere in the document - after all transactions are pretty central to RDBMS systems...

Michael

[Abigail-II]

Error checking is an idiom in itself.

Is it? If you were to discuss idiom for reading in a file line-by-line, would you present something like:

    open my $fh, "/path/to/file";
    while (<$fh>) {
        chomp;
        ...
    }

and dismiss the checking of the return value of open "it being an idiom in itself"? Error checking should be part of the idiom, and not something you bolt on later, when you are more experienced.

Abigail
--
Now that you have passed your driving test, let me introduce you to the function of safety belts.

[demerphq]

would you present something like:

Hmm, I guess you would be upset with me if I wrote that as

@ARGV=qw(/path/to/file);
while (<>) {
        chomp;
        ...
}

which of late ive taken to doing in quick and dirty scripts? *grin*


---
demerphq

_{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}

[Abigail-II]

Hmm, I guess you would be upset with me if I wrote that as

...

which of late ive taken to doing in quick and dirty scripts?

Only if you present that as "Perl idiom" in a tutorial.

Abigail

[ibm1620]

I, for one, appreciate that you've focused on just one thing. This stuff is confusing enough as it is.