On Sun, Oct 06, 2002 at 02:59:13PM -0400, Sam Tregar wrote:
> On Sun, 6 Oct 2002, Tim Bunce wrote:
>
> > I'd suggest that the method be
> > called flush_to_disk() (and passed an optional filehandle).
> > flush_to_disk() could just call dump_to_disk() then discard_data().
>
> Sounds reasonable to me. I'll still need to do something about format()
> though, since otherwise the one I inherit from DBI::Profile will still be
> available.
That's not a problem in itself. What you probably want to do is override DESTORY.
But rather than do that I'd suggest changing DBI::Profile something like this:
sub on_destroy {
my $self = shift;
my $detail = $self->format() if $self->{Data};
DBI->trace_msg($detail, 0) if $detail;
}
sub DESTROY {
my $self = shift;
eval { $self->on_destroy };
if ($@) {
my $class = ref($self) || $self;
DBI->trace_msg("$class format failed: $@", 0);
}
}
(patches welcome :)
Then override on_destroy() in DBI::ProfileDumper so it calls flush_to_disk().
> > I'd add a general name=value section here (matching /^(\w+)=(.*)$/) that
> > can be used to store information like the Path being used, $0, @ARGV,
> > etc.
>
> Good idea. However, is it useful to store the Path here? DBI::Profile
> allows the user to change their Path during the run, so the last value of
> Path can't really be used to in the analysis of the profile data.
Does no harm, with caveats in the docs.
Tim.
