test suite

Add thread CV locks (not method locks)
to &DBI::connect and &DBI::connect_cached
in xs dbi_init code.

Complete and test connect_cached

fetch_scroll handling via get_fbav.
Also add:
	getrow_array       (or getdata_?)
	getrow_arrayref
	getrow_hashref

test that $dbh->do will RaiseError
RaiseError in %attr - doc it not working - hints.

Consider RaiseError in re do() method and when to croak

SQL_ACTIVE_STATEMENTS

Consider making all SQL_ known to the DBI. Want to check for
valid spelling. Also would like C<exists $h->{Attrib}> to
work. Maybe auto load a module that defines a private hash
that just serves to list known attributes.

t/shell uninit var at 5.00502/Term/Cap.pm line 284.

check out http://tegan.deltanet.com/~phlip/DBUIframe.html

FAQ check 80 col max

Shell!

Document NAME_lc etc

If trace log_where() says DBI.pm then use caller(1)?

Auto proxying for individual drivers: DBI_PROXY_foo=...

Check DBI works okay with tainting.

Check DBD::Proxy connect&fetch latency (e.g. CGI use).

Complete connect_cached().

Add TYPE, SCALE, PRECISION to DBD::Sponge

$dbh->get_info?

Bundle DBD::Xbase?
Bundle Tie::DBI?
Bundle others

Add $dbh->{BusyCallback} = sub { ... } hook so drivers which support
polling can allow other processing without complicating the logic.

Add per-handle debug file pointer (or at least a macro that _looks_ like that).
Or, better yet, a function pointer so we can do more clever things.

Rework handle creation for
$h->clone ?, and maybe
$dbh->connect([$user, $passwd])	# to reconnect, possibly as a different user

generic dbd_preparse (for both C and perl)

SQL Parser
  CPAN/authors/id/JAKE/perl5-byacc-patches-0.5.tar.gz

Fix shared error codes between handles!

Add problem reporting info to DBI.pm

Metadata!

Add DBI::set_err to DBI::DBD.pm docs

Add 'break handling' when field values change? Use two fbav's so 'previous
record' is available. Defind break fields and handlers. Call them via
an alternate fetch_with_break method.


---
> > Is there any way to know whether a particular DBD needs a separate
> > connection for nested operations or not?

Umm, it looks like $dbh->{SQL_ACTIVE_STATEMENTS} would be the one.
It defines the max number of statements that can be active on a
the $dbh. 0 means unknown or no specific limit.
I'll add that to the DBI and DBI spec.

I think drivers that emulate multiple active statements using an
implicit extra dbh but that can't tie the commit/rollback on the
'parent' dbh to the child should probably still set
SQL_ACTIVE_STATEMENTS to just 1. Or maybe 1.1, or 2. I'm open to
suggestion on that one.

-----------
> > > I would prefer to set this attributes on statement level [as 
> > > an attribute to prepare()] instead of setting it via $dbh,
> > > but this is only a detail. 
> > 
> > You can set it any any level. Isn't that clear from the docs?
> 
> As I understand the doc, it is possible to do
> 
>     $sth = $dbh->prepare("....");
>     $sth->execute();
>     $sth->{LongReadLen} = 80;
>     @foo = $sth->fetchrow();
>     $sth->{LongReadLen} = 4096;
>     @bar = $sth->fetchrow(); 
> 
> so that the fetch of the second row is done with a different 
> {LongReadLen} value ? 
> 
> This sounds complicated with the current structure of DBD::Solid,
> as I have only one buffer for the entire row allocated during
> prepare(), but I must admit that I had no time [yet] to look 
> into the last DBD::ODBC how you handle this case.

Umm. I see what you mean. It's reasonable to assume that a driver
will 'freeze' the value of applicable attributes at prepare or execute
time. The driver should probably document that kind of thing.

I think the DBI's template .xst file will probably grow some code
to handle attributes to prepare semi-automatically, sometime.

Tim.
----------- 
