> Comments welcome.
Just some random thoughts that came from reading this.
What about Multiple result set statements/more_results? (i.e. select * from
foo; select * from bar; or calling stored procs which have multiple
statements within them as per Sybase & SQL*Server, etc)
[snip]
>
> =head2 Unicode
>
> Use of Unicode with the DBI is growing rapidly. The DBI could
> do more to help drivers support Unicode and help applications
> work with drivers that don't yet support Unicode directly.
>
> * Define expected behavior for fetching data and binding parameters.
>
> * Fix 'leaking' of UTF8 flag from one row to the next.
Hmmmm....Am I missing something here, but wouldn't a column that has UTF8
data *always* have UTF8 data within a statement (resetting only between
statements, such as multiple-result-set statements?
>
> * Provide interfaces to support Unicode issues for XS and
> pure Perl drivers and applications.
Please! :)
> =head2 Testing
>
> The DBI has a test suite. Every driver has a test suite.
> Each is limited in its scope. The driver test suite is
> testing for behavior that matches what the driver author
> thinks the DBI specifies but may be subtly incorrect. These
> test suites are poorly maintained because the development
> cost is relatively high compared to the "return" from a single driver.
>
[snip]
YES
YES
I'd love one, since DBD::ODBC has to jump through those hoops itself and has
some tests which vary depending upon the connection. I think it would be *a
good thing* to have generic tests and database specific tests. Some
advantages, I think, are:
DBD::ODBC and DBD::ADO testing...generally the same types of issues
crop up where one is "better" than the other right now or neither do the
job.
DBD::ODBC when connected to Sybase|Sql*Server vs DBD::Sybase. With
the exception of the bulk API, I'd like them to behave the same way.
etc. (yes, lofty, but that's the goal, isn't it :)
[snip]
>
> * The popular fetchrow_hashref() method is many times slower than
> fetchrow_arrayref() because it has to re-get the names of the
> fields each time. A $h->{FetchHashReuse} attribute would
> allow the same hash to be reused each time making
> fetchrow_hashref() about the same speed as fetchrow_arrayref().
Why does it have to re-get the names each time? Why not tie the names in
with the "more_results" functionality?
[snip]
>
> The goal is not to fully parse the SQL and rewrite it in a
> different dialect. That's well beyond the scope of the DBI
> and should be left to layered modules. However, a simple
> token rewriting mechanism for five comment styles, two
> quoting styles, four placeholder styles, plus the ODBC "{foo
> ...}" escape syntax is sufficient to significantly raise the
> level of SQL portability.
Yes!
>
> * Another major problem area is date/time formatting. Since
> version 1.41 the DBI has defined a way to express that dates
> should be fetched in SQL standard date format (YYYY-MM-DD).
> However it requires the
> bind_col() method to be called on applicable columns. This
> is one example of the more general case where bind_col()
> needs to be called with particular attributes on all columns
> of a particular type.
>
> A mechanism is needed whereby an application can specify
> default bind_col() attributes for each column type. So with a
> single step all DATE type columns, for example, can be set to
> be returned in the standard format.
Double YES!
>
> * Integration with the Perl debugger would make it simpler to
> perform actions on a per-handle basis (such as breakpoint on
> execute, breakpoint on error).
Very cool! Esp with threads :)
[snip]
>
>
> =head2 Parrot and Perl 6
>
[snip]
>
> (The project stalled, due to Parrot not having key
> functionality at the time, and has yet to be restarted.)
Does Parrot yet have the support we need? If so, I must have missed it.
>
> The bulk of the DBI code actually exists in base classes
> 'behind' the driver API. The method dispatcher code that
> Perl applications interface with is relatively small.
>
> Each language targeting Parrot would implement their own
> small language-specific dispatcher over the Parrot DBDI interface.
>
> A "big win" here is that a much wider community of developers
> share the same database drivers and so the benefits of the
> Open Source model are magnified.
>
> The bulk of the work will be translating the C and Perl base
> class code into Parrot PIR or a suitable language that generates PIR.
Yech, I mean Yep. :)
Regards,
Jeff
