Re: [sqlite] request to become co-maintainer of DBD::SQLite
Dear Duncan, thanks for taking on this job! I have recently started using SQLite quite heavily from Perl scripts -- it is astonishingly efficient, even for simple queries on a 70 GB database (Google's Web 1T 5-gram database, in case someone's curious) with Perl callback functions -- so I'd be more than happy to see an up-to-date version of DBD::SQLite. Since I'm lazy enough to rely on OS-provided SQLite installations on various computers, I'm using at least three different old versions of SQLite in parallel, DBD::SQLite being the oldest of all ... (no compatibility problems at all, though, so kudos to all SQLite developers!). I have been stuck back at 3.4 for various issues. I do Perl and C and offer some help. Same here. I feel reasonably at home both in C and Perl, and I've written some simple XS code. I don't have any experience with DBI, which seems to have its own method of compiling C extensions for DBD modules (from a quick look at the DBD::SQLite sources). Just let us know how/whether we can help you! Best regards, Stefan Evert [ stefan.ev...@uos.de | http://purl.org/stefan.evert ]
Re: [sqlite] request to become co-maintainer of DBD::SQLite
Hi, I would like to highlight the fact the in large corporations, bumping DBI to new version is a major issue, as the module serve as a foundation for hundreds of applications, which must be retested on every change. As a result, large companies will bump DBI version every few years. Also, large companies usually prefer to use vendor provided software. Red Hat 4 is bundled with DBI 1.40, and Red Hat 5 is bundled with 1.52. While this may not be the latest and greatest, this is the reality for many development projects. My 2 cents - If possible, DBD drivers should be compatible with older version as long as practically possible. This will make newer SQLite versions viable option for most projects. Yair -Original Message- From: Darren Duncan [mailto:dar...@darrenduncan.net] Sent: Wednesday, January 14, 2009 9:19 PM To: General Discussion of SQLite Database; DBI Dev Subject: Re: [sqlite] request to become co-maintainer of DBD::SQLite These are replies to posts on the sqlite-users list. However, if there is going to be ongoing discussion I prefer it happen on the dbi-dev list. Not that sqlite-users isn't very on topic itself, dbi-dev just seems *more* on topic, I think. Clark Christensen wrote: One of my first code changes will be to require DBI 1.607+ The current DBD-SQLite works fine under older versions of DBI. So unless there's a compelling reason to do it, I would prefer you not make what seems like an arbitrary requirement. I have 2 answers to that: 1. Sure, I can avoid changing the enforced dependency requirements for now, leaving them as Matt left them. However, I will officially deprecate support for the older versions and won't test on them. If something works with the newer dependencies but not the older ones, it will be up to those using or supporting the older dependencies to supply fixes. 2. On one hand I could say, why not update your DBI when you're updating DBD::SQLite, since even the DBI added lots of fixes one should have. On the other hand, I can understand the reality that you may have other legacy modules like drivers for other old databases that might break with a DBI update. I say might, since on the other hand they might not break. Still, I'll just go the deprecation angle for now. Otherwise, it sounds like a good start. Matt must be really busy with other work. I'll be happy to contribute where I can, but no C-fu here, either :-( Thank you. Ribeiro, Glauber wrote: My only suggestion at the moment, please use the amalgamation instead of individual files. This makes it much easier to upgrade when SQLite releases a new version. Okay. Jim Dodgen wrote: I'm for the amalgamation too. the rest of you ideas are great also. excelent idea to use Audrey Tangs nameing convention. I have been stuck back at 3.4 for various issues. I do Perl and C and offer some help. Okay and thank you. -- Darren Duncan
Re: [sqlite] request to become co-maintainer of DBD::SQLite
I am not sure agree. Companies that don't upgrade DBI releases are unlikely to upgrade DBD drivers more frequently; and they're always free to use older DBD releases. We don't want to hold developers hostage to the tendency of a few companies to be slow in upgrades. At my workplace, a large corporation, we make multiple DBI and DBD::xxx releases available, and applications can choose their own versions. It'd be unfortunate if useful new DBI features would not be used by current DBD::xxx releases. That's not to say that incompatibility should be introduced just for fun. But if a DBD driver wants to use a new DBI feature, and that breaks compatibility with older DBI releases, the DBD driver author should go ahead. The Makefile.PL file for the DBD module will specify the minimal DBI release required. yair lenga wrote: Hi, I would like to highlight the fact the in large corporations, bumping DBI to new version is a major issue, as the module serve as a foundation for hundreds of applications, which must be retested on every change. As a result, large companies will bump DBI version every few years. Also, large companies usually prefer to use vendor provided software. Red Hat 4 is bundled with DBI 1.40, and Red Hat 5 is bundled with 1.52. While this may not be the latest and greatest, this is the reality for many development projects. My 2 cents - If possible, DBD drivers should be compatible with older version as long as practically possible. This will make newer SQLite versions viable option for most projects. Yair -Original Message- From: Darren Duncan [mailto:dar...@darrenduncan.net] Sent: Wednesday, January 14, 2009 9:19 PM To: General Discussion of SQLite Database; DBI Dev Subject: Re: [sqlite] request to become co-maintainer of DBD::SQLite These are replies to posts on the sqlite-users list. However, if there is going to be ongoing discussion I prefer it happen on the dbi-dev list. Not that sqlite-users isn't very on topic itself, dbi-dev just seems *more* on topic, I think. Clark Christensen wrote: One of my first code changes will be to require DBI 1.607+ The current DBD-SQLite works fine under older versions of DBI. So unless there's a compelling reason to do it, I would prefer you not make what seems like an arbitrary requirement. I have 2 answers to that: 1. Sure, I can avoid changing the enforced dependency requirements for now, leaving them as Matt left them. However, I will officially deprecate support for the older versions and won't test on them. If something works with the newer dependencies but not the older ones, it will be up to those using or supporting the older dependencies to supply fixes. 2. On one hand I could say, why not update your DBI when you're updating DBD::SQLite, since even the DBI added lots of fixes one should have. On the other hand, I can understand the reality that you may have other legacy modules like drivers for other old databases that might break with a DBI update. I say might, since on the other hand they might not break. Still, I'll just go the deprecation angle for now. Otherwise, it sounds like a good start. Matt must be really busy with other work. I'll be happy to contribute where I can, but no C-fu here, either :-( Thank you. Ribeiro, Glauber wrote: My only suggestion at the moment, please use the amalgamation instead of individual files. This makes it much easier to upgrade when SQLite releases a new version. Okay. Jim Dodgen wrote: I'm for the amalgamation too. the rest of you ideas are great also. excelent idea to use Audrey Tangs nameing convention. I have been stuck back at 3.4 for various issues. I do Perl and C and offer some help. Okay and thank you. -- Darren Duncan
Re: [sqlite] request to become co-maintainer of DBD::SQLite
These are replies to posts on the sqlite-users list. However, if there is going to be ongoing discussion I prefer it happen on the dbi-dev list. Not that sqlite-users isn't very on topic itself, dbi-dev just seems *more* on topic, I think. Clark Christensen wrote: One of my first code changes will be to require DBI 1.607+ The current DBD-SQLite works fine under older versions of DBI. So unless there's a compelling reason to do it, I would prefer you not make what seems like an arbitrary requirement. I have 2 answers to that: 1. Sure, I can avoid changing the enforced dependency requirements for now, leaving them as Matt left them. However, I will officially deprecate support for the older versions and won't test on them. If something works with the newer dependencies but not the older ones, it will be up to those using or supporting the older dependencies to supply fixes. 2. On one hand I could say, why not update your DBI when you're updating DBD::SQLite, since even the DBI added lots of fixes one should have. On the other hand, I can understand the reality that you may have other legacy modules like drivers for other old databases that might break with a DBI update. I say might, since on the other hand they might not break. Still, I'll just go the deprecation angle for now. Otherwise, it sounds like a good start. Matt must be really busy with other work. I'll be happy to contribute where I can, but no C-fu here, either :-( Thank you. Ribeiro, Glauber wrote: My only suggestion at the moment, please use the amalgamation instead of individual files. This makes it much easier to upgrade when SQLite releases a new version. Okay. Jim Dodgen wrote: I'm for the amalgamation too. the rest of you ideas are great also. excelent idea to use Audrey Tangs nameing convention. I have been stuck back at 3.4 for various issues. I do Perl and C and offer some help. Okay and thank you. -- Darren Duncan
