
*** Assorted to-do items and random thoughts *** in no particuar order ***

Primary Key metadata

Change bind_column to save the info for get_fbav to use when
first called. Thus making bind before execute reliable.

Add a handle flag to say that the driver has a hash that maps error
codes into SQLSTATE values. The error event mechanism could check for
the flag and lookup the SQLSTATE value for the error from the hash.

ODBC attribute defining if transactions are supported

> I had to override
> tables from DBD::_::db because it doesn't handle the quoting
> conventions used by Informix databases.  Basically, table owners
> are case sensitive in some databases, and therefore need to be
> enclosed in double quotes (delimited identifier).
: Needs attribute to say that a) double-quotes can be used
: and b) that names are case sensitive.

$dbh-level __WARN__ and __DIE__. Initially just provide DBIXS hooks
for DBD's to use (and pass h and imp_xxh to). Thus $dbh can redirect
errors etc from all children in one go.

Allow first arg to bind_columns to be not supplied.

Informix inspired changes.

Detect it in eval block for when PrintError and RaiseError are both set.

selectcol_arrayref

Add hook to DBI::DBD to write a myconfig.txt file into the
source directory containing key driver and config info.

dbi:Driver(AutoCommit=0;PrintError=1):dsn	- overrides \%attribs hash

attribute for 'last inserted id'

test suite

$sth->{Database} and $dbh->{Driver} should hold the
outer handle not the inner one.

$sth->more_results, now and $sth->become($sth2) later

dbish - state AutoCommit status clearly at connect time.
(Or try to set AutoCommit off.)

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

Complete and test connect_cached, inc proxy.

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.
Or DBI->SQL_FOO and/or DBI::SQL_FOO.

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!

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 (dbh) 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.
----------- 
