On Sun, 6 Oct 2002, Tim Bunce wrote:
> > =head1 USAGE
> >
> > The normal way to use this module is just to enable it in your C<$dbh>:
> >
> > $dbh->{Profile} = "DBI::ProfileDumper";
>
> I'd suggest you suggest that people use the DBI_PROFILE env var.
Ok. I'll also include that in a DBI::Profile doc patch I'm cooking up.
> > To collect data before the process ends, you can call the C<format()>
> > method:
> >
> > $dbh->{Profile}->format();
> >
> > Calling this methods will empty the currently held profile data and
> > flush it to disk.
>
> 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.
> 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.
> I'd add an extra record-type field at the front of each row
> (or at least the profile data records). Perhaps something like:
>
> @ + SELECT name FROM users WHERE id = ?
> @ ++ prepare
> = 1 0.0312958955764771 0.000490069389343262 0.00....
Ok.
> > The key strings are transformed in two ways. First, all backslashes
> > are doubled. Then all newlines are transformed into C<\n>. When
> > DBI::ProfileData reads the file these transformations will be reversed.
>
> Might be wise to also escape \r.
Right.
Thanks!
-sam
