On Fri, Jul 09, 2004 at 01:09:29PM +0200, Jochen Wiedmann wrote:
> Tim Bunce wrote:
>
> >And it wasn't easy. Withdrawing support for 5.6 anytime soon would
> >be _much_ harder. Coupling that with a major change in the DBI that
> >may require some application code changes (however small and rare)
> >just makes the hurdle higher and create more reasons to stay with 5.6
> >and DBI v1.
> >
> >Having said that, I've no problem declaring that 5.8 is the recommended
> >version and that support for 5.6 will be withdrawn "at some point".
>
> I do not get your point Tim. IMO the whole point for v2 would be that
>
> - A true rewrite should be possible, whereever desired.
> - It is possible for the maintainers to get rid of some stuff. (You
> know better than I, what would be worth getting rid of and I know
> a lot.)
> - Whoever wants to use the new version is welcome and
> - Whoever doesn't want, is fine.
>
> I accept, that the DBI is an important application. But your points are,
> IMO, an indicator, that v1 should receive further maintenance, perhaps by
> someone else.
As I've said previously, DBI v2.0 is mainly about changes to the DBI<->DBD
interface.
Here's the list of changes that may break _applications_:
Redefine tables() to default to tables accessible from current
schema without further qualification.
Turning AutoCommit on should trigger rollback not commit.
(ODBC does a commit) This will break code that assumes a commit.
Always taint check the $sql for do() and prepare()
if perl is in taint mode (can't be disabled).
Default TaintIn=>1 in perl taint mode?
Default TaintOut=>1 in perl taint mode but exclude placeholders?
plus these odds-n-ends that are much lower risk:
Remove support for "old-style" connect syntax
(where the driver name is the 4th parameter).
Change undocumented DBI->err and DBI->errstr methods to warn.
Remove old informix fudge in tables() (would only impact people
using very old DBD::Informix versions as it now has it's own).
That's a very small list and, although it's early days, I hope to
keep it that way.
>From the users point of view upgrading to DBI v2 should be relatively
painless. Driver maintainers will have a little more work to do,
but I'll aim to make that as painless as possible as well.
(Start by using the new dbivport.h and the macros it contains
as that'll be a key mechanism for migration.)
I'm _suggesting_ that it's also an opportunity for driver maintainers
to "get rid of some stuff" but it's up to them how far they want to
take that.
Tim.
