ANNOUNCE: DB_File-1.50 Beta
Quote:
> > The 1.14 release is identical to the version of DB_File that is
> > included with Perl 5.003_99.
> > The 1.50 release is beta code which can build with either Berkeley DB
> > version 1 or version 2 (but not both simultaneously). When built with
> > DB 2.0 it only supports the functionality available in DB 1.x.
> > Anywhere the version 2 interface differs, DB_File arranges for it to
> > work like version 1. This feature allows DB_File scripts that were
> > built with version 1 to be migrated to version 2 without any changes.
> > A future version of DB_File which will support the new features
> > available in Berkeley DB 2.x is currently under construction.
> Paul on release of DB_File could you sync your version numbers with
> that of the DBM from Berkeley. Or better yet name the package
> DB_File2 This way we can have both Berkely DB's and not have to worry
> about compatibility. Issues for those LARGE perl instalations that
> have TONS of scripts.
I'd like to second this. Berkeley DB 2.x is incompatible with 1.85, and
even uses a non-conflicting interface so the old and new DB libraries
can coexist peacefully. Given how different DB 2.x is and the fact that
they could coexist, why not make DB_File2 to access the 2.x library and
keep DB_File for the 1.x version?
Even discounting backwards-compatibility with existing scripts, there
are applications where DB 2.x is a WORSE choice than DB 1.85, such as
CGI scripts that only need simple hash table lookup, but can't afford
heavy startup penalties. DB 2.x has more startup overhead than 1.x, so
it would not make sense to "upgrade" such an application if it doesn't
need any of the new features. Yes, DB 2.x is faster in general, but
there are exceptions. And it's definitely more complex.
So, how about it? Have both DB_File and DB_File2, and maintain them
separately?
Deven
P.S. I'd love to see locking added to DB_File for version 1.85 -- this
should VERY straightforward to implement, since DB will hand over a file
descriptor on request, and Perl already supports several locking
mechanisms directly in the "flock" operator. It might not work in all
situations, but it would be a start... (I'd be happy to take a stab at
writing this.)