On Fri 09 Jul 2004 14:10, Tim Bunce <[EMAIL PROTECTED]> wrote:
> 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.
Why not create a new method call, as you (IMHO) should have done in 1.38
The change of behaviour in the tables () method is a straightforward nightmare
for me. Adding those quotations broke about all my applications.
I have added my own tables method in the wrapper I always use, where I just
remove all the quotes again, so the change is now rather small. You said it
should have been done much earlier, but I still disagree in that this approach
was very wrong.
> 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).
These two lines belong together, right? Like in
if ($perl_is_in_taint_mode) {
check_taint ($sql) if $method in qw( do prepare );
}
> 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.
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.0 & 633 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.024 &/| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
