On Jan 23, 2008 2:07 PM, Ted Zlatanov <[EMAIL PROTECTED]> wrote:
> I found one of the problems is that you forcibly set RaiseError to 1 in
> a lot of places, in Rose::DB and Rose::DB::Object.  Why override the
> connect_options?
> My code is working with do_transaction for now, but begin_work/commit
> should really be shown with an eval in the Rose::DB SYNOPSIS.  I got the
> impression they would not die from the Rose::DB docs, so their
> exceptions were killing an outer eval, and rollback() was not called...
> I'd show you the code but it's not interesting or pretty.

The only instances I can think of off the top of my head are
local()ized changes so that I can use eval blocks internally for error
handling.  For example:

  sub whatever
      local $dbh->{'RaiseError'} = 1;
      # do stuff

    if($@) { ... } # handler error
    else   { ... } # or success

If there's an instance where RaiseError is altered outside and eval
block and/or not changed back before a sub returns, it's probably a
bug, so send me any cases you've found that demonstrate this.

> I ran with DBI_TRACE set high and checked that the DBD commit was only
> called as many times as I specified.  So I'm using transactions to
> insert the rows, and RDBO is just not able to handle the load for my
> particular task.  With COPY FROM, I can insert about 10-20 times faster
> than RDBO, so I'll have to stick with that.  I'll mimic the RDBO SQL
> statements and just run them I guess...

Did you try plain DBI?  I suspect even that will be 10-15 times slower
than COPY FROM.  Native bulk loading is always going to win, by a lot.


This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Rose-db-object mailing list

Reply via email to