Skip Menu |
 

This queue is for tickets about the DBD-SQLite CPAN distribution.

Report information
The Basics
Id: 18788
Status: resolved
Priority: 0/
Queue: DBD-SQLite

People
Owner: Nobody in particular
Requestors: adamk [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: Fork a variant for distributable SQLite dbs
Download (untitled) / with headers
text/plain 661b
The main DBD::SQLite dist keeps upgrading the bundled SQLite database. This is fine, except when you want to create a SQLite database for wide distribution as a container for some published data. I'm not sure how hard this would be, but it would be nice if there was a way to have a DBD::SQLiteV3 (or something) fork, that was the same as the main one, but bundled the oldest version of SQLite that the current version is capable of reading safely. So, I imagine it would be 3.0.0 or something? In any case, using this alternative version would mean you could use seperate drivers for 1. Generating distributable database files 2. Doing your normal stuff.
From: bart.lateur [...] pandora.be
Download (untitled) / with headers
text/plain 315b
It appears to me that using a driver of the generation of 3.3.0, should be fine: Version 3.3.0 can read and write database files created by prior versions of SQLite. But prior versions of SQLite will not be able to read or write databases created by Version 3.3.0 http://www.sqlite.org/formatchng.html
Subject: Re: [rt.cpan.org #18788] Fork a variant for distributable SQLite dbs
Date: Tue, 09 May 2006 00:03:09 +1000
To: bug-DBD-SQLite [...] rt.cpan.org
From: Adam Kennedy <adam [...] phase-n.com>
Download (untitled) / with headers
text/plain 718b
Well, using the current 3.3.5 for example to generate published data, this means that someone with DBD::SQLite as recent as 1.09 may not be able to read the file. By using 3.0.0 (or nearish) it means all versions 1.00 or never can read it, as well as slightly older things in other languages. Adam K Guest via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=18788 > > > It appears to me that using a driver of the generation of 3.3.0, should > be fine: > > Version 3.3.0 can read and write database files created by prior > versions of SQLite. But prior versions of SQLite will not be able > to read or write databases created by Version 3.3.0 > > http://www.sqlite.org/formatchng.html
From: bart.lateur [...] pandora.be
Download (untitled) / with headers
text/plain 922b
On Mon May 08 10:06:14 2006, adam@phase-n.com wrote: Show quoted text
> Well, using the current 3.3.5 for example to generate published data, > this means that someone with DBD::SQLite as recent as 1.09 may not be > able to read the file.
Oh, right. We were talking about different things. I was thinking about what driver is safe to distribute with an app, so it can read people's databases. You're thinking what database version is safe to distribute to use with any module version. That is a serious problem with SQLite, IMO: the file format changes too often, and a newer version of the program isn't able to produce a database in a previous version. I'd rather thing of a data conversion tool, so all you have to do is convert the database to an older version before distributing it. But anyway, following the instructions for converting from SQLite2 to SQLite3, the text format of the dump should be usable for exchanging data.
Subject: Re: [rt.cpan.org #18788] Fork a variant for distributable SQLite dbs
Date: Tue, 09 May 2006 09:44:57 +1000
To: bug-DBD-SQLite [...] rt.cpan.org
From: Adam Kennedy <adam [...] phase-n.com>
Download (untitled) / with headers
text/plain 1.7k
Hmm... using a text dump might just be good enough. Leave this bug open for now, and once the new DBIx::Class::Loader API turns up and we get a chance to experiment with doing SQLite published data I'll let you know how it goes. Only problem might be that some of the data sets being planned are huge, in the order of several hundred meg. I'm wondering if the load time for large data sets is going to be a concern, if there's a million or so records in a data set (and a few planned data sets are that big), at a notional 1,000 inserts a second that means a good 20 minutes of importing. There's also a smaller issue regarding bloat, but it's minor in comparison. I'll get back to you on the export file solution. Adam K Guest via RT wrote: Show quoted text
> <URL: http://rt.cpan.org/Ticket/Display.html?id=18788 > > > On Mon May 08 10:06:14 2006, adam@phase-n.com wrote:
>> Well, using the current 3.3.5 for example to generate published data, >> this means that someone with DBD::SQLite as recent as 1.09 may not be >> able to read the file.
> > Oh, right. We were talking about different things. I was thinking about > what driver is safe to distribute with an app, so it can read people's > databases. You're thinking what database version is safe to distribute > to use with any module version. > > That is a serious problem with SQLite, IMO: the file format changes too > often, and a newer version of the program isn't able to produce a > database in a previous version. > > I'd rather thing of a data conversion tool, so all you have to do is > convert the database to an older version before distributing it. But > anyway, following the instructions for converting from SQLite2 to > SQLite3, the text format of the dump should be usable for exchanging data.
Closing my own bug, to reduce the bug count :)


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.