On Tue, Dec 21, 2004 at 10:53:04AM +0100, Krzysztof Krzyzaniak wrote:
> > Just out of curiosity: how can a DBD not be backwards compatible?
> > I understand that the underlying engine might not be backwards
> > compatible. Do you perhaps mean that there are SQL statements
> > that SQLite 2 executed that SQLite 3 doesn't?
> I mean you cannot use you database files created with sqlite2 with
> new DBD::SQLite package.
Oh, that's what you mean. Yes, the on-disk format is not backwards
compatible, taht's the reason why I don't understand why the
DBD::SQLite author chose to keep that name instead of DBD::SQLite3.
The API is not compatible either, but AFAIUI from the POV of a Perl
program this is not of much importance since this is accessed thru DBI.
Yes, you can extend the DBI API with methods from the underlying engine
but I don't know to which extend this is actually used by authors.
My point is, this module should be called (upstream) DBD::SQLite3. The
old one should keep its name. Can you talk with upstream about this?
> > What do you mean "manually linked"?
> I mean adding in Makefile.PL of lidbd-sqlite2-perl
> 'LIBS' => "-lsqlite",
> 'LIBS' => "-lsqlite3",
> in libdbd-sqlite3-perl package.
You do realize that DBD::SQLite includes the (almost) full SQLite
source code? I've been always tickled by that. This is the reason why
Makefile.PL doesn't list the library (or for that matter, why SQLite is
not needed at all to build or use DBD::SQLite)
> > It comes out fine here.
What I meant by this was that "make test" works as expected. I hadn't
understood what you meant...
> > Fine, but that doesn't really address the problem of existing
> > programs breaking, does it? What happens when both
> > libdbd-sqlite2-perl and libdbd-sqlite-perl are installed and one
> > of these programs gets run?
> Should be no problem with that. But I haven't test heavily that
> because I don't have any sqlite3 databases yet (except testing one).
I don't think you understand me -- my fault for saying too much at once.
program.pl reads partially:
my $dbh = DBI->connect("dbi:SQLite:dbname=dbfile","","");
and dbfile has been created with SQLite 2
Now the system is upgraded and the newer libdbd-sqlite-perl gets
installed. That means the above line will still work fine (because
there is a DBD::SQLite) but data can't be retrieved from the database
because the on-disk format has changed.
Now the user installs the "old" libdbd-sqlite2-perl. The program still
works but the data still can't be retrieved.
Point is, with both libdbd-sqlite2-perl and libdbd-sqlite-perl what you
have is a silent error: Perl can't tell you that it can't find
DBD::SQLite because there's one there and since the correct one has a
different name, it can't tell you to fix that either. I haven't looked
into DBD::SQLite, but I guess it does raise an error telling you
that the database is in an older format. If it doesn't it should.
That said, I do have an DBD::SQLite that links dynamically against
sqlite3, but I don't know why the author chose a different path.