On Tue, 21 Jun 2005 01:13:21 +0100, Tim Bunce wrote:
> On Sun, Jun 19, 2005 at 06:16:25AM -0700, Peter Scott wrote:
>> On Sat, 18 Jun 2005 15:34:36 +0100, Tim Bunce wrote:
>> > On Fri, Jun 17, 2005 at 05:49:01PM -0700, Peter Scott wrote:
>> >> The connected() method of subclasses doesn't get all the attribute
>> >> that were set by the caller; three of them are deleted first:
>> [snip]
>> >> Likewise - and this is more debatable - the $dsn passed to
>> >> connected() has had the driver prefix stripped off so you can't tell
>> >> which driver was used.
> I'm writing a subclass designed to ensure that inserts coming in a
>> continuous stream get to the database even if the connection is down
>> and they have to be buffered on local disk pending retries. (It only
>> has to handle inserts and the transaction issues are understood.) So
>> my subclass is going to fire off a subprocess that does the actual
>> connection to the database and reconnects whenever necessary, while the
>> parent writes insert statements to files, looking to the user like a
>> regular DBI interface (although it will claim that all do()s succeed,
>> will signal fatal errors through a SIGCHLD handler croaking, and will
>> probably croak on a fetch). (Furthermore, I'll have to timeout connects
>> and do()s in a couple of seconds due to the data rate.) It's my first
>> DBI subclass and I've only just started, so I may have to revise that
>> design some, but that's the current idea. Therefore I'm planning on
>> capturing the connect info from connected() before the fork.
>
> Seems a little over the top to try to keep the DBI abstraction,
> especially as data volumes and performance are significant here.
The idea was to make the applications that use this module trivially
convertible to DBI itself if someone decides that the effort to make sure
that every byte is sacred was not worth the overhead. However...
> I'd probably just modify the application to write delimited files and
> have a separate process handle the loading.[*]
Your suggestion of using a bulk loader sounds worth revising that goal. In
this case it would be the Oracle loader. I haven't used that before
myself, but we are getting an expert in it shortly so I can assume that he
can make it do anything we want :-)
> I'm reluctant to change, but the legacy expectations of the connected()
> method are low so I'm open to persuasion.
Now that it doesn't appear that I need that patch, I can easily be talked
out of it :-) In fact, the original arguments are copied to an array
@orig_args that is never used, so it looks as though the original intent
was to do it this way. But whether there's a subclass out there that
would be confounded by the change to $dsn, I don't know. Nevertheless,
this passes all the DBI tests:
--- DBI.pm.orig 2005-06-21 06:07:05.279603094 -0700
+++ DBI.pm 2005-06-21 06:34:44.061949532 -0700
@@ -650,7 +650,9 @@
}
# if we've been subclassed then let the subclass know that we're
connected
- $dbh->connected($dsn, $user, $pass, $attr) if ref $dbh ne 'DBI::db';
+ # We'll normalize the dsn first
+ $dbh->connected("dbi:$driver($driver_attrib_spec):$dsn",
@orig_args[1..3])
+ if ref $dbh ne 'DBI::db';
# if the caller has provided a callback then call it
# especially useful with connect_cached() XXX not
enabled/tested/documented
--
Peter Scott
http://www.perlmedic.com/
http://www.perldebugged.com/
