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

Re: libdbd-sqlite-perl



Dnia 21-12-2004, wto o godzinie 09:51 -0600, Marcelo E. Magallon
napisał(a):
> Hi,
> 
> 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)

Hmm. Indeed.

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.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=283896

//---
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
two 
packages libdbd-sqlite2-perl & libdbd-sqlite3-perl and drop
libdbd-sqlite-perl package. 
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). 

  eloy
-- 
* Allegro.pl / Aukro.cz / Tetrako.hu
* Krzysztof 'eloy' Krzyżaniak
* <eloy@allegro.pl>



Reply to: