[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libdbd-sqlite-perl


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",
 > and
 >     '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.


Reply to: