Dnia 21-12-2004, wto o godzinie 09:51 -0600, Marcelo E. Magallon
> 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?
I can of course. I will forward this discussion (since is on public
list) and ask for changing name to DBD::SQLite3.
> > > 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)
So my effort with linking is completly useless.
> > > 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.
dbd-sqlite-perl reports below error message.
DBD::SQLite::db prepare failed: file is encrypted or is not a
database(26) at dbdimp.c line 263 at ./a.pl line 11.
> 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.
I see only one soulution here (before any changes from upstream). Create
packages libdbd-sqlite2-perl & libdbd-sqlite3-perl and drop
I cannot use "old" DBD::SQlite package compatible with sqlite2 because
it doesn't compile on others architectures. I have to use new
DBD::SQLite2 package to pass this problem (I am not good C hacker, I am
not able to backport changes from DBD::SQLite2 to dbd::sqlite < 1.0).
* Allegro.pl / Aukro.cz / Tetrako.hu
* Krzysztof 'eloy' Krzyżaniak