Re: [sqlite] first DBD::SQLite for SQLite 3.x released
At 1:46 PM +0800 7/23/04, Ng Pheng Siong wrote: I'd imagine keeping DBD::SQLite for v2 and creating DBD::SQLite3 for v3 is the most straightforward approach. Actually, I just thought of a counter-example that may work even better. I propose that the existing DBD::SQLite name keep going as it is now, embedding all of the newest SQLite releases, including 3.x and onward. To effectively deal with multiple versions, I propose releasing the current 2.x version in a module called DBD::SQLite2 (if done now, it would contain 2.8.15). If this approach is used, then programs that only need to deal with database files that they themselves create will not need to be updated at all; only programs that actually want to deal with both v2 files and v3 files will need updating, to open the old files with DBD::SQLite2. An alternate solution would be for DBD::SQLite to embed both 2.x and 3.x in it, with some switch to DBI's connect() function determining which to use, if new 2.x files are to be created, or no API change if not (all new files are v3). However, I don't particularly recommend this for the standard version because it makes DBD::SQLite bloated, even if that may actually be the most user friendly. -- Darren Duncan
Re: [sqlite] first DBD::SQLite for SQLite 3.x released
On Thu, Jul 22, 2004 at 08:56:50PM -0700, Darren Duncan wrote: > The simplest answer for both of these is to use DBD::SQLite 0.31 for > version 2 databases, and DBD::SQLite 1.0 for version 3 databases. If > you mean, use them both simultaneously, then that's more complicated, > and I won't go into it now. -- Darren Duncan I'd imagine keeping DBD::SQLite for v2 and creating DBD::SQLite3 for v3 is the most straightforward approach. Ditto for Python, Ruby, etc. etc. Cheers. -- Ng Pheng Siong <[EMAIL PROTECTED]> http://firewall.rulemaker.net -+- Cisco PIX & Netscreen Config Version Control http://sandbox.rulemaker.net/ngps -+- M2Crypto, ZServerSSL for Zope, Blog
Re: [sqlite] first DBD::SQLite for SQLite 3.x released
On Thursday 22 July 2004 8:56 pm, Darren Duncan wrote: > At 11:22 PM -0400 7/22/04, [EMAIL PROTECTED] wrote: > >Scott Leighton <[EMAIL PROTECTED]> writes: > > > OK, but what happens to existing sqlite databases we're already > >> > >> using with Perl? From what I can see, if I update to the new > >> DBD:SQLite, I'll end up with v 3.x even though all my existing > >> db's are v 2.8. Will it auto-detect and upgrade them? > > > >And what of read-only databases (e.g. those databases which have been > > written to CD or DVD) and can't be upgraded? Can they still be queried? > > The simplest answer for both of these is to use DBD::SQLite 0.31 for > version 2 databases, and DBD::SQLite 1.0 for version 3 databases. I don't see that as a viable option. > If > you mean, use them both simultaneously, then that's more complicated, > and I won't go into it now. -- Darren Duncan I think it will be a problem if they can't coexist somehow. Otherwise, the poor user would have to locate and convert any SQLite databases on their machine (and in their archives) before one could successfully upgrade to the new DBD::SQLite without breaking things. Scott -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.5-7.95-default x86_64
Re: [sqlite] first DBD::SQLite for SQLite 3.x released
At 11:22 PM -0400 7/22/04, [EMAIL PROTECTED] wrote: Scott Leighton <[EMAIL PROTECTED]> writes: > OK, but what happens to existing sqlite databases we're already using with Perl? From what I can see, if I update to the new DBD:SQLite, I'll end up with v 3.x even though all my existing db's are v 2.8. Will it auto-detect and upgrade them? And what of read-only databases (e.g. those databases which have been written to CD or DVD) and can't be upgraded? Can they still be queried? The simplest answer for both of these is to use DBD::SQLite 0.31 for version 2 databases, and DBD::SQLite 1.0 for version 3 databases. If you mean, use them both simultaneously, then that's more complicated, and I won't go into it now. -- Darren Duncan
Re: [sqlite] first DBD::SQLite for SQLite 3.x released
Scott Leighton <[EMAIL PROTECTED]> writes: > On Thursday 22 July 2004 2:40 pm, Darren Duncan wrote: >> Good news. And since Matt hasn't brought it up here yet, I will. >> >> Yesterday, Matt Sergeant posted DBD::SQLite v1.0 on CPAN, which is >> the first version to incorporate SQLite v3.x. >> >> Suffice it to say, you actually can start using SQLite 3 in Perl now. > > > OK, but what happens to existing sqlite databases we're already > using with Perl? From what I can see, if I update to the new > DBD:SQLite, I'll end up with v 3.x even though all my existing > db's are v 2.8. Will it auto-detect and upgrade them? And what of read-only databases (e.g. those databases which have been written to CD or DVD) and can't be upgraded? Can they still be queried? Cheers, Derrell
Re: [sqlite] first DBD::SQLite for SQLite 3.x released
On Thursday 22 July 2004 2:40 pm, Darren Duncan wrote: > Good news. And since Matt hasn't brought it up here yet, I will. > > Yesterday, Matt Sergeant posted DBD::SQLite v1.0 on CPAN, which is > the first version to incorporate SQLite v3.x. > > Suffice it to say, you actually can start using SQLite 3 in Perl now. OK, but what happens to existing sqlite databases we're already using with Perl? From what I can see, if I update to the new DBD:SQLite, I'll end up with v 3.x even though all my existing db's are v 2.8. Will it auto-detect and upgrade them? Scott -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.5-7.95-default x86_64
[sqlite] first DBD::SQLite for SQLite 3.x released
Good news. And since Matt hasn't brought it up here yet, I will. Yesterday, Matt Sergeant posted DBD::SQLite v1.0 on CPAN, which is the first version to incorporate SQLite v3.x. Suffice it to say, you actually can start using SQLite 3 in Perl now. And this means that *I* can now start putting it through its paces, and writing programs to use it. -- Darren Duncan
