test DBD::SQLite 1.30_04 - write-ahead logging
All, I am pleased to announce that DBD::SQLite (Self Contained RDBMS in a Perl DBI Driver) version 1.30_04 has been released on CPAN (by Adam Kennedy). http://search.cpan.org/~adamk/DBD-SQLite-1.30_04/ This developer release bundles the brand-new SQLite version 3.7.2, which (since 3.7.0) adds support for write-ahead logging (WAL). See http://sqlite.org/wal.html for the details of the WAL support that SQLite now has. WAL is an alternative method to how SQLite implements atomic commit and rollback than to its rollback journal method. It offers much improved concurrency and performance in many circumstances, such as because database readers and writers don't block each other. There are also trade-offs. By default, SQLite and DBD::SQLite will continue to use the older rollback journal method, and you can use the new WAL method with the SQL command: PRAGMA journal_mode=WAL; There are also numerous other additions, changes, or fixes in either DBD::SQLite or SQLite itself since the last production DBD::SQLite release 1.29 of 2010 January, which bundles SQLite 3.6.22. For the change details since then, see http://sqlite.org/changes.html or http://search.cpan.org/src/ADAMK/DBD-SQLite-1.30_04/Changes as appropriate. TESTING NEEDED! Please bash the hell out of the latest DBD::SQLite and report any outstanding bugs on RT. Test your dependent or compatible projects with it, which includes any DBMS-wrapping or object persistence modules, and applications. This 1.30_04 release will probably be released as a production 1.31 within a week if no show-stopper problems are found. Please note the compatibility caveats of using pre-3.7.x versions of SQLite on databases that had been used with WAL mode on. In order to use an older SQLite on the database, the database must have last been used by a 3.7.x in journal mode. See http://sqlite.org/wal.html for details. Please note that, if you receive nondescript "disk I/O error" errors from your code after the update, see if the failing code involves a process fork followed by unlinking of the database, such as if it was temporary for testing. The DBD::SQLite test suite had needed an update to act more correctly, which the update to 3.7.x from 3.6.x exposed; 3.6.x didn't complain about this. If you want in to DBD::SQLite development, then join the following email/IRC forums which MST created (the mailing list, I am administrating): http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite #dbd-sqlite on irc.perl.org And the canonical version control is at: http://svn.ali.as/cpan/trunk/DBD-SQLite/ Patches welcome. Ideas welcome. Testing welcome. If you feel that a bug you find is in SQLite itself rather than the Perl DBI driver for it, the main users email forum for SQLite in general is at: http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ... where you can report it as an appropriate list post (the SQLite issue tracking system is no longer updateable by the public; posting in the list can cause an update there by a registered SQLite developer). Please do not reply to me directly with your responses. Instead send them to the forums or file with RT as is appropriate. Thank you. -- Darren Duncan
ANN - DBD::SQLite 1.27 - test it!
All, I am pleased to announce that DBD::SQLite (Self Contained RDBMS in a Perl DBI Driver) version 1.27 has been released on CPAN (by Adam Kennedy). http://search.cpan.org/~adamk/DBD-SQLite-1.27/ This release is the newest one intended for production use and has no known serious bugs. The previous version for production was 1.25, which was released on 2009 April 23. There were many improvements and changes between these 2 versions, and many bugs fixed; see http://cpansearch.perl.org/src/ADAMK/DBD-SQLite-1.27/Changes for a complete list. Just a small number of these are, since 1.25: - The bundled SQLite is version is now 3.6.20, up from 3.6.13 (both were the Amalgamation). - Foreign key constraints are now supported and enforceable by SQLite. However, to aid backwards compatibility and give you a transition period to ensure your applications work with them, this feature is not enabled by default. You enable (or disable) foreign key enforcement by issuing a pragma. - Read the Changes file linked above, especially the sections that say "changes which may possibly break your old applications". As usual, testing of this release is appreciated and recommended. If you use referential stuff in your schema (which SQLite ignores by default now) should do extensive testing to ensure that they will work when you issue "PRAGMA foreign_keys = ON". It is anticipated that foreign keys will be enabled by default within 1 or 2 production releases, and you will have to cope with it. If you want in to DBD::SQLite development, then join the following email/IRC forums which MST created (the mailing list, I am administrating): http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite #dbd-sqlite on irc.perl.org And the canonical version control is at: http://svn.ali.as/cpan/trunk/DBD-SQLite/ Patches welcome. Ideas welcome. Testing welcome. Whining is also welcome! If you feel that a bug you find is in SQLite itself rather than the Perl DBI driver for it, the main users email forum for SQLite in general is at: http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ... where you can report it as an appropriate list post (the SQLite issue tracking system is no longer updateable by the public; posting in the list can cause an update there by a registered SQLite developer). Please do not reply to me directly with your responses. Instead send them to the forums or file with RT as is appropriate. Thank you. -- Darren Duncan
test DBD::SQLite 1.26_06 please
All,
I am pleased to announce that DBD::SQLite (Self Contained RDBMS in a Perl DBI
Driver) version 1.26_06 has been released on CPAN (by Adam Kennedy).
http://search.cpan.org/~adamk/DBD-SQLite-1.26_06/
TESTING NEEDED!
Please bash the hell out of the latest DBD::SQLite and report any outstanding
bugs on RT. Test your dependent or compatible projects with it, which includes
any DBMS-wrapping or object persistence modules, and applications.
This developer release includes both several changes which *might break your
applications* if not accounted for, and it has a lot of code refactoring.
This release should also fix the known problem with full-text search (FTS3) that
was reported in the 1.26_05 release but had existed in many prior versions; the
included test for that problem now passes.
From the Changes file:
*** CHANGES THAT MAY POSSIBLY BREAK YOUR OLD APPLICATIONS ***
- Removed undocumented (and most probably unused) reset method
from a statement handle (which was only accessible via func().)
Simply use "$sth->finish" instead. (ISHIGAKI)
- Now DBD::SQLite supports foreign key constraints by default.
Long-ignored foreign keys (typically written for other DB
engines) will start working. If you don't want this feature,
issue a pragma to disable foreign keys. (ISHIGAKI)
- Renamed "unicode" attribute to "sqlite_unicode" for integrity.
Old "unicode" attribute is still accessible but will be
deprecated in the near future. (ISHIGAKI)
- You can see file/line info while tracing even if you compile
with a non-gcc compiler. (ISHIGAKI)
- Major code refactoring. (ISHIGAKI)
- Pod reorganized, and some of the missing bits (including
pragma) are added. (ISHIGAKI)
The bundled SQLite version (3.6.19) is unchanged from last time.
If you want in to DBD::SQLite development, then join the following email/IRC
forums which MST created (the mailing list, I am administrating):
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
#dbd-sqlite on irc.perl.org
And the canonical version control is at:
http://svn.ali.as/cpan/trunk/DBD-SQLite/
Patches welcome. Ideas welcome. Testing welcome. Whining is also welcome!
If you feel that a bug you find is in SQLite itself rather than the Perl DBI
driver for it, the main users email forum for SQLite in general is at:
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
... where you can report it as an appropriate list post (the SQLite issue
tracking system is no longer updateable by the public; posting in the list can
cause an update there by a registered SQLite developer).
Please do not reply to me directly with your responses. Instead send them to
the forums or file with RT as is appropriate.
Thank you. -- Darren Duncan
Re: test DBD::SQLite 1.26_05 - foreign keys!
On Oct 14, 2009, at 11:39 PM, Darren Duncan wrote:
Also be sure to look at the section http://sqlite.org/foreignkeys.html#fk_enable
, because you have to enable a pragma on each connect to use the
foreign keys feature; it isn't yet on by default for backwards
compatibility purposes.
I suggest you add something to the documentation showing how to always
enable this using a callback. Something like
my $enable_fks = sub { shift->do('PRAGMA foreign_keys = ON') };
my $dbh = DBI->connect($dsn, '', '', {
Callbacks => { connect => $enable_fks, },
});
If the user uses connect_cached, she should use this instead:
Callbacks => { 'connect_cached.reused' => $enable_fks, },
Best,
David
Re: [DBD-SQLite] test DBD::SQLite 1.26_05 - foreign keys!
Please note the following correction to the announcement. Whining is also welcome. :) Adam K 2009/10/15 Darren Duncan : > Patches welcome. Ideas welcome. Testing welcome. Whining to /dev/null.
test DBD::SQLite 1.26_05 - foreign keys!
All, I am pleased to announce that DBD::SQLite (Self Contained RDBMS in a Perl DBI Driver) version 1.26_05 has been released on CPAN (by Adam Kennedy). http://search.cpan.org/~adamk/DBD-SQLite-1.26_05/ This developer release bundles the brand-new SQLite version 3.6.19, which adds support for enforcing SQL foreign keys. See http://sqlite.org/foreignkeys.html for the details of the foreign key support that SQLite now has. Also be sure to look at the section http://sqlite.org/foreignkeys.html#fk_enable , because you have to enable a pragma on each connect to use the foreign keys feature; it isn't yet on by default for backwards compatibility purposes. As I imagine many of you have been pining away for SQLite to support this feature for a long while, you'll want to dig in right away. TESTING NEEDED! Please bash the hell out of the latest DBD::SQLite and report any outstanding bugs on RT. Test your dependent or compatible projects with it, which includes any DBMS-wrapping or object persistence modules, and applications. And especially try actually using foreign keys with SQLite. As the official release announcement says: "This release has been extensively tested (we still have 100% branch test coverage). [The SQLite developers] consider this release to be production ready. Nevertheless, testing can only prove the presence of bugs, not their absence. So if you encounter problems, please let us know." See also http://www.sqlite.org/changes.html for a list of everything else that changed in SQLite itself over the last few months. If you want in to DBD::SQLite development, then join the following email/IRC forums which MST created (the mailing list, I am administrating): http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite #dbd-sqlite on irc.perl.org And the canonical version control is at: http://svn.ali.as/cpan/trunk/DBD-SQLite/ Patches welcome. Ideas welcome. Testing welcome. Whining to /dev/null. If you feel that a bug you find is in SQLite itself rather than the Perl DBI driver for it, the main users email forum for SQLite in general is at: http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ... where you can report it as an appropriate list post (the SQLite issue tracking system is no longer updateable by the public; posting in the list can cause an update there by a registered SQLite developer). Please do not reply to me directly with your responses. Instead send them to the forums or file with RT as is appropriate. Thank you. -- Darren Duncan P.S. DBD::SQLite has at least 1 known bug, also in version 1.25, with regard to full-text search (FTS3); there is an included new failing test, which currently is set to skip so the CPAN testers don't issue fails, but the issue behind it should hopefully be fixed before the next DBD::SQLite release. We decided that shipping DBD::SQLite now with the skipping test was preferable to waiting for that fix so you could get the new foreign keys feature the soonest.
ANN - DBD::SQLite version 1.24_01 - amalgamation
All, I am pleased to announce that DBD::SQLite (Self Contained RDBMS in a DBI Driver) version 1.24_01 has been released on CPAN (by Adam Kennedy). http://search.cpan.org/~adamk/DBD-SQLite-1.24_01/ The main feature of this release is that now DBD::SQLite also uses amalgamated source recommended at sqlite.org, meaning that the entire C source code of the SQLite library itself is now contained in a single file rather than being spread over several dozen files. Some advantages of this change include better performance due to cross-file optimization, and also an easier compilation on platforms with more limited make systems. The last DBD::SQLite release that doesn't use the amalgamated source is version 1.23, which was released 2 days earlier. Also the bundled SQLite library with both 1.23 and 1.24_01 has been updated to v3.6.13 from v3.6.12 that 1.20 had. Further improvements in 1.24_01 over 1.20 involve mainly a significant modernization of the whole test suite, so it uses Test::More, and also there were more bugs fixed, minor enhancements made, and RT items addressed. See http://cpansearch.perl.org/src/ADAMK/DBD-SQLite-1.24_01/Changes as well as http://sqlite.org/changes.html for details. Given that the switch to amalgamated SQLite sources is arguably a very large change (or arguably a very small change), mainly in subtle ways that might affect build/compile systems (though actual SQLite semantics should be identical), ... Please bash the hell out of the latest DBD::SQLite and report any outstanding bugs on RT. Test your dependent or compatible projects with it, which includes any DBMS-wrapping or object persistence modules, and applications. If you want in to DBD::SQLite development, then join the following email/IRC forums which MST created (the mailing list, I am administrating): http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite #dbd-sqlite on irc.perl.org And the canonical version control is at: http://svn.ali.as/cpan/trunk/DBD-SQLite/ Patches welcome. Ideas welcome. Testing welcome. Whining to /dev/null. Note that today's switch to amalgamated sources is the last major short term change to DBD::SQLite that I personally expected would happen (sans updates to the bundled SQLite library itself), but other developers probably have their own ideas for what directions the development will go next. Please do not reply to me directly with your responses. Instead send them to the forums or file with RT as is appropriate. Thank you. -- Darren Duncan
Re: ANN - DBD::SQLite version 1.20
Congrats guys - glad this finally came about. On Tue, 7 Apr 2009, Darren Duncan wrote: All, I am pleased to announce that DBD::SQLite (Self Contained RDBMS in a DBI Driver) version 1.20 has been released on CPAN. http://search.cpan.org/dist/DBD-SQLite/ This follows on the heels of 10 developer releases released starting 2009 March 27th (Adam "Alias" Kennedy has been doing release management). The previous production release of DBD::SQLite was version 1.14 about 18 months ago. Improvements in 1.20 over 1.14 include: * Updated the bundled SQLite library from v3.4.2 to v3.6.12, which carries many new features as well as bug fixes. * Added support for user-defined collations. * Added ->column_info(). * Resolved all but a handful of the 60+ RT items. * Many bug fixes and minor enhancements. * Added more tests, large refactoring of tests. * Minimum dependencies are now Perl 5.006 and DBI 1.57. See http://cpansearch.perl.org/src/ADAMK/DBD-SQLite-1.20/Changes as well as http://sqlite.org/changes.html for details. Now it is especially important, since automatic updates from CPAN such as with the CPAN/CPANPLUS utilities, would now be pulling this new 1.20 by default, ... Please bash the hell out of the latest DBD::SQLite and report any outstanding bugs on RT. Test your dependent or compatible projects with it, which includes any DBMS-wrapping or object persistence modules, and applications. If you want in to DBD::SQLite development, then join the following email/IRC forums which MST created (the mailing list, I am administrating): http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite #dbd-sqlite on irc.perl.org And the canonical version control is at: http://svn.ali.as/cpan/trunk/DBD-SQLite/ Patches welcome. Ideas welcome. Testing welcome. Whining to /dev/null. Regarding near future plans: Now, the current 1.20 uses the pristine several-dozen SQLite library source files, same as 1.14 did. While reality may be different, I believe that the next major planned change to DBD::SQLite is to substitute in the "amalgamation" version, which combines all the SQLite source files into a single file; the amalgamation is the recommended form for users according to the SQLite core developers. See http://sqlite.org/download.html for a description of that. Meanwhile there should be another stable release with any bug fixes for 1.20 to come out first. Any other major changes or features for DBD::SQLite are expected to come out separately from and after the stabilized switch to the amalgamation sources. Please do not reply to me directly with your responses. Instead send them to the forums or file with RT as is appropriate. Thank you. -- Darren Duncan
ANN - DBD::SQLite version 1.20
All, I am pleased to announce that DBD::SQLite (Self Contained RDBMS in a DBI Driver) version 1.20 has been released on CPAN. http://search.cpan.org/dist/DBD-SQLite/ This follows on the heels of 10 developer releases released starting 2009 March 27th (Adam "Alias" Kennedy has been doing release management). The previous production release of DBD::SQLite was version 1.14 about 18 months ago. Improvements in 1.20 over 1.14 include: * Updated the bundled SQLite library from v3.4.2 to v3.6.12, which carries many new features as well as bug fixes. * Added support for user-defined collations. * Added ->column_info(). * Resolved all but a handful of the 60+ RT items. * Many bug fixes and minor enhancements. * Added more tests, large refactoring of tests. * Minimum dependencies are now Perl 5.006 and DBI 1.57. See http://cpansearch.perl.org/src/ADAMK/DBD-SQLite-1.20/Changes as well as http://sqlite.org/changes.html for details. Now it is especially important, since automatic updates from CPAN such as with the CPAN/CPANPLUS utilities, would now be pulling this new 1.20 by default, ... Please bash the hell out of the latest DBD::SQLite and report any outstanding bugs on RT. Test your dependent or compatible projects with it, which includes any DBMS-wrapping or object persistence modules, and applications. If you want in to DBD::SQLite development, then join the following email/IRC forums which MST created (the mailing list, I am administrating): http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite #dbd-sqlite on irc.perl.org And the canonical version control is at: http://svn.ali.as/cpan/trunk/DBD-SQLite/ Patches welcome. Ideas welcome. Testing welcome. Whining to /dev/null. Regarding near future plans: Now, the current 1.20 uses the pristine several-dozen SQLite library source files, same as 1.14 did. While reality may be different, I believe that the next major planned change to DBD::SQLite is to substitute in the "amalgamation" version, which combines all the SQLite source files into a single file; the amalgamation is the recommended form for users according to the SQLite core developers. See http://sqlite.org/download.html for a description of that. Meanwhile there should be another stable release with any bug fixes for 1.20 to come out first. Any other major changes or features for DBD::SQLite are expected to come out separately from and after the stabilized switch to the amalgamation sources. Please do not reply to me directly with your responses. Instead send them to the forums or file with RT as is appropriate. Thank you. -- Darren Duncan
Re: RFC: developing DBD::SQLite
On Mar 28, 2009, at 12:40 AM, Darren Duncan wrote: I'm not a pushover. It's more that I wasn't strongly opinionated on the matter in the first place and I was fishing; your response led to me realizing that a simpler plan of action was better (and less work for both me and others). (Less work)++ And that's the end of this thread I think. (Thread death)++ :-) Best, David
Re: RFC: developing DBD::SQLite
David E. Wheeler wrote: On Mar 27, 2009, at 2:39 AM, Darren Duncan wrote: I have tried emailing Matt several times without response already. Should I try telephoning him next? For all it looks like, Matt has abandoned the module. If someone knows better, or has been in contact recently, I'd be happy to hear. Looks like he responded to someone emailing him without CC'ing a mail list. I had also done that initially, before another post CC'ing a mail list. But anyway, it doesn't matter any more as the issue is resolved. Wow, I didn't know that you would be such a pushover. ;-) I don't use DBD::SQLite myself for any production purposes, and it has been a while since I've used it at all, so you should lean harder one people who really depend on it than on opinionated assholes like me. I'm not a pushover. It's more that I wasn't strongly opinionated on the matter in the first place and I was fishing; your response led to me realizing that a simpler plan of action was better (and less work for both me and others). And that's the end of this thread I think. -- Darren Duncan
Re: RFC: developing DBD::SQLite
On Mar 27, 2009, at 2:39 AM, Darren Duncan wrote: I have tried emailing Matt several times without response already. Should I try telephoning him next? For all it looks like, Matt has abandoned the module. If someone knows better, or has been in contact recently, I'd be happy to hear. Looks like he responded to someone emailing him without CC'ing a mail list. So following your response, I will eliminate a lot of the change items from my plan. In particular, I will continue to bundle the SQLite library as it has always been done, and won't download anything. I will also not add the version.pm dependency and will continue numbering releases where Matt left off, such as starting at version 1.15 or jumping up a bit and starting at 1.20_01 which should be harmless. In regards to which version to use, I will also leave that behaviour as Matt had it; his version could either use the bundled version or the system version, and I'll leave selecting which to the same mechanism Matt had it, unless the users argue for a change. I think that means the bundled is the default. Wow, I didn't know that you would be such a pushover. ;-) I don't use DBD::SQLite myself for any production purposes, and it has been a while since I've used it at all, so you should lean harder one people who really depend on it than on opinionated assholes like me. So then, what I'm planning to do is this then: 1. Enter DBD::SQLite into public version control using Git, with the initial version being the last one Matt published on CPAN, and then I will merge in Audrey Tang's changes that were released as DBD::SQLite::Amalgamation; essentially there is no change but that several dozen SQLite library files are replaced with a single one. 2. Then I'll update the library to the latest one on sqlite.org, and then retest and deal with anything that breaks. 3. Then I'll look at various open RT items and apply various submitted bug fixes, again testing. And I'll accept collaborative fixes from other people such as those made against the version control. 4. Then I'll put an experimental-versioned release on CPAN. Looks like you and the DBIx team hit this today. Congrats! In fact, despite the larger sized releases, this probably is actually much less work for me when it comes down to it due to less complexity. I really will just make the minimal changes possible from Matt's version, just to get it to run with the current SQLite library, which will now be the single amalgamation file. Also mainly the driver would just be tested and asserted by me to work with the version of SQLite bundled with it. (Less work)++ And if users replace the bundled amalgamation file with a different amalgamation file, generally it'll act as if the replacement was the original, so this isn't really a separate case. Right, good call. Now I know you said prefer system, but to start I'll just leave it the way Matt had it; mind you, if there is a general consensus to change this default, I'll honor it. That works. And my current plans are now back to what they were earlier this year when I proposed co-maintaining the driver, a focus on minimalism, before I became more ambitious in today's first proposal. It pays to be less ambitious at first, methinks: Get things working and stable again, and go from there. Best, David
ANN - DBD::SQLite version
All, I am pleased to announce that DBD::SQLite (Self Contained SQLite RDBMS in a DBI Driver) version 1.19_01 has been released on CPAN. http://search.cpan.org/~adamk/DBD-SQLite-1.19_01/ This is the first CPAN release of DBD::SQLite since version 1.14 about 18 months ago. This is the change summary since 1.14: 1.19_01 Fri 27 Mar 2009 - Updated to SQLite 3.6.10, and bumped up the version requirement for installed sqlite3 to 3.6.0 as 3.6.x has backward incompatiblity (ISHIGAKI) - fixed "closing dbh with active statement handles" issue with a patch by TOKUHIROM. (ISHIGAKI) - skip 70schemachange test for Windows users. (ISHIGAKI) - applied RT patches including #29497, #32723, #30558, #34408, #36467, #37215, #41047. (ISHIGAKI) - added TODO to show which issues are to be fixed. (ISHIGAKI) - license and configure_requires in Makefile.PL and META.yml (Alexandr Ciornii) - Spelling check for SQLite.pm (Alexandr Ciornii) - Adding arbitrary Perl 5.005 minimum Right now, DBD::SQLite has a new development team with Matt Sergeant's blessing, which is working to keep it updated and fix any outstanding bugs. Multiple people have made commits to it since Jan 24th. I am serving a role as project advocate among other things. So please bash the hell out of the latest DBD::SQLite and report any outstanding bugs on RT. Test your dependent or compatible projects with it, which includes any DBMS-wrapping or object persistence modules, and applications. And yes we are aware that 3.6.10 isn't the latest; that will be fixed soon. If you want in to DBD::SQLite development, then join the following email/IRC forums which MST created (the mailing list, I am administrating): http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite #dbd-sqlite on irc.perl.org Some discussion has also taken place in the dbi-dev list and there is also a general DBI related IRC channel, but the above DBD-SQLite forums were just created last night. The version control is the one Adam "Alias" Kennedy setup around January 24th, which is a Subversion repo. Here are some change log and browse urls: http://fisheye2.atlassian.com/changelog/cpan/trunk/DBD-SQLite http://svn.ali.as/cpan/trunk/DBD-SQLite/ Patches welcome. Ideas welcome. Testing welcome. Whining to /dev/null. In particular, we can use more people with C savvy, as we are somewhat bereft of that among the current team. For one thing, apparently using the amalgamation file from sqlite.org is incompatible with the XS code that talks to the multiplicity of original SQLite source code files, so some savvy is needed to patch it for that migration. Please do not reply to me directly with your responses. Instead send them to the forums or file with RT as is appropriate. Thank you. -- Darren Duncan
Re: RFC: developing DBD::SQLite
On Fri, 27 Mar 2009, Greg Sabino Mullane wrote: I have tried emailing Matt several times without response already. Did you cc modu...@perl.org? What did they say? They've been helpful with me in the past in tracking module owners down. I very rarely read mailing list mail these days - my life got too busy for it, so if you want to contact me directly you MUST NOT CC a mailing list, because otherwise my procmail will just dump it in a folder I'll never read. Matt.
Re: DBD::SQLite new maintenance plan
On Fri, Mar 27, 2009 at 01:16:58PM +0100, H.Merijn Brand wrote: > On Fri, 27 Mar 2009 22:18:01 +1100, Adam Kennedy > wrote: > > > http://svn.ali.as/cpan/releases/DBD-SQLite-1.19_01.tar.gz > > DBD::SQLite-1.19_01 from trunk on HP-UX 10.20: Please can you send failures like this to the mailing list rather than to me directly - I've been bootstrapping project infrastructure, I'm not enough of a C monkey to really understand what just went wrong :) -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
Fwd: RFC: developing DBD::SQLite
Amalgamation what the SQLite maintainers recommend, and it's the most portable, etc. So this is the right choice. Also, given the way SQLite is maintained (backward compatibility is fairly strict, they jump through hoops in their API to make it so), bundling is fine, and is intended by the designers. I agree it can be a slight hassle to update to the current amalgamation, run tests, and then release on CPAN, but that cycle can be made pretty short. Having the *ability* to use installed libraries... say on a system where the installed libs are newer/threadsafe/being tested, whatever, is a useful feature. But, in my experience, it was only needed because the DBD::Sqlite *wasn't* being well maintained. If it had been, I would have just used the new DBD::Sqlite and never worried about it. The DBD::SQlite should use a) already installed libs if *available and compatible* b) *bundled* amalgamation, which is guaranteed to be available and compatible That's it.
Re: DBD::SQLite new maintenance plan
This is the first version of DBD::SQLite in a long time which runs the test suite with no errors on Fedora. net1#uname -a Linux net1.coolsurf.com 2.6.27.19-170.2.35.fc10.i686 \ #1 SMP Mon Feb 23 13:21:22 EST 2009 i686 i686 i386 GNU/Linux Thanks! Adam Kennedy wrote: http://svn.ali.as/cpan/releases/DBD-SQLite-1.19_01.tar.gz Uploaded to PAUSE just now. 2009/3/27 Matt S Trout : On Fri, Mar 27, 2009 at 09:24:36AM +, Matt S Trout wrote: I don't think dbi-dev is a good place for it - how about I provision a dbd-sqlite list on scsys and an IRC channel on perl.org? The last batch of tweaking was done with the help of @dbic-devel so I figure stuffing the community on the same infrastructure is probably no bad thing. -!- Topic for #dbd-sqlite: http://svn.ali.as/cpan/trunk/DBD-SQLite/ | http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite Right. Want in to DBD::SQLite development? Join the IRC channel or join the list. Patches welcome. Ideas welcome. Testing welcome. Whining to /dev/null or I come after you with a chainsaw. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ -- Love feeling your best ever, all day, every day? Click http://RadicalHealth.com/join for the easy way.
Re: RFC: developing DBD::SQLite
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > I have tried emailing Matt several times without response already. Did you cc modu...@perl.org? What did they say? They've been helpful with me in the past in tracking module owners down. > In particular, I will continue to bundle the SQLite library as it has > always been done, and won't download anything. +1 > I will also not add the version.pm dependency and will continue numbering > releases where Matt left off, such as starting at version 1.15 or jumping > up a bit and starting at 1.20_01 which should be harmless. - -1. Three part version numbers are the proper way to do things. Might as well make the change now, all at once. As far as moving things to yet another mailing list, and/or yet another IRC channel on perl.org that nobody visits, I'd much prefer that things stay here on dbi-dev, so that other driver authors can learn from your experiences, and we can contribute back in turn. If it gets high traffic and extraordinarily sqlite-specific, then, yes, use another list, but I'd lean towards keeping it here if possible. Thanks for all your work in driving this forward. - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200903271007 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAknM3fQACgkQvJuQZxSWSshf1wCePIehoa8NF3EdGwl3Bga7R6T/ Sj0AoKWmUFDBGB5+Dly0bJWn5lDPrhB7 =NO4U -END PGP SIGNATURE-
Re: takeover request - DBD::SQLite
On Fri, 27 Mar 2009 09:24:36 +, Matt S Trout wrote: > On Fri, Mar 27, 2009 at 02:09:33AM -0700, Darren Duncan wrote: > > Hello Steffen et al, thanks for your response. > > > > I was not previously aware that Adam had taken this up; no mention of it in > > any forums I frequent nor on CPAN. But I'm very happy to hear it > > nonetheless. > > > > If Adam is serious about this and wants to organize the effort to keep > > DBD::SQLite up to date, then I'm quite happy to step back from trying to > > start my own effort. The main reason I offered to take over or co-maintain > > back around Jan 12th was because the module seemed to be abandoned and no > > one else was stepping up. So I'm happy and prefer to join Adam's effort > > rather than doing a separate one. > > Adam and I have been discussing this with Matt Sergeant for some time and > he was happy with it. > > I don't think dbi-dev is a good place for it - how about I provision a > dbd-sqlite list on scsys and an IRC channel on perl.org? The last batch of > tweaking was done with the help of @dbic-devel so I figure stuffing the > community on the same infrastructure is probably no bad thing. There already is an IRC channel on perl.org : #dbi, withe very very low traffic -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.3, 11.0, and 11.1, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::SQLite new maintenance plan
On Fri, 27 Mar 2009 22:18:01 +1100, Adam Kennedy wrote: > http://svn.ali.as/cpan/releases/DBD-SQLite-1.19_01.tar.gz DBD::SQLite-1.19_01 from trunk on HP-UX 10.20: cc -c -I. -I/pro/lib/perl5/site_perl/5.8.8/PA-RISC2.0/auto/DBI -Ae +DAportable +Z -z -D_HPUX_SOURCE -Wl,+vnocompatwarnings -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 +O2 +Onolimit -DVERSION=\"1.19_01\" -DXS_VERSION=\"1.19_01\" +Z "-I/pro/lib/perl5/5.8.8/PA-RISC2.0/CORE" -DSQLITE_CORE -DSQLITE_ENABLE_FTS3 -DNDEBUG=1 -DSQLITE_PTR_SZ=4 -DHAVE_USLEEP=1 -DTHREADSAFE=0 os_unix.c cpp: "os_unix.c", line 3841: error 4036: Can't open include file 'dlfcn.h'. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.3, 11.0, and 11.1, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: DBD::SQLite new maintenance plan
http://svn.ali.as/cpan/releases/DBD-SQLite-1.19_01.tar.gz Uploaded to PAUSE just now. 2009/3/27 Matt S Trout : > On Fri, Mar 27, 2009 at 09:24:36AM +, Matt S Trout wrote: >> I don't think dbi-dev is a good place for it - how about I provision a >> dbd-sqlite list on scsys and an IRC channel on perl.org? The last batch of >> tweaking was done with the help of @dbic-devel so I figure stuffing the >> community on the same infrastructure is probably no bad thing. > > -!- Topic for #dbd-sqlite: http://svn.ali.as/cpan/trunk/DBD-SQLite/ | > http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite > > Right. Want in to DBD::SQLite development? Join the IRC channel or join > the list. > > Patches welcome. Ideas welcome. Testing welcome. Whining to /dev/null or I > come after you with a chainsaw. > > -- > Matt S Trout Need help with your Catalyst or DBIx::Class project? > Technical Director http://www.shadowcat.co.uk/catalyst/ > Shadowcat Systems Ltd. Want a managed development or deployment platform? > http://chainsawblues.vox.com/ http://www.shadowcat.co.uk/servers/ >
DBD::SQLite new maintenance plan
On Fri, Mar 27, 2009 at 09:24:36AM +, Matt S Trout wrote: > I don't think dbi-dev is a good place for it - how about I provision a > dbd-sqlite list on scsys and an IRC channel on perl.org? The last batch of > tweaking was done with the help of @dbic-devel so I figure stuffing the > community on the same infrastructure is probably no bad thing. -!- Topic for #dbd-sqlite: http://svn.ali.as/cpan/trunk/DBD-SQLite/ | http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite Right. Want in to DBD::SQLite development? Join the IRC channel or join the list. Patches welcome. Ideas welcome. Testing welcome. Whining to /dev/null or I come after you with a chainsaw. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
Re: takeover request - DBD::SQLite
On Fri, Mar 27, 2009 at 02:09:33AM -0700, Darren Duncan wrote: > Hello Steffen et al, thanks for your response. > > I was not previously aware that Adam had taken this up; no mention of it in > any forums I frequent nor on CPAN. But I'm very happy to hear it > nonetheless. > > If Adam is serious about this and wants to organize the effort to keep > DBD::SQLite up to date, then I'm quite happy to step back from trying to > start my own effort. The main reason I offered to take over or co-maintain > back around Jan 12th was because the module seemed to be abandoned and no > one else was stepping up. So I'm happy and prefer to join Adam's effort > rather than doing a separate one. Adam and I have been discussing this with Matt Sergeant for some time and he was happy with it. I don't think dbi-dev is a good place for it - how about I provision a dbd-sqlite list on scsys and an IRC channel on perl.org? The last batch of tweaking was done with the help of @dbic-devel so I figure stuffing the community on the same infrastructure is probably no bad thing. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
(Fwd) [Dbix-class] DBD::SQLite new maintenance plan
- Forwarded message from Matt S Trout - Date: Fri, 27 Mar 2009 10:24:36 + From: Matt S Trout To: dbix-cl...@lists.scsys.co.uk Subject: [Dbix-class] DBD::SQLite new maintenance plan Reply-To: "DBIx::Class user and developer list" List-Id: "DBIx::Class user and developer list" List-Archive: <http://lists.scsys.co.uk/pipermail/dbix-class> -!- Topic for #dbd-sqlite: http://svn.ali.as/cpan/trunk/DBD-SQLite/ | http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite Right. Want in to DBD::SQLite development? Join the IRC channel or join the list. Patches welcome. Ideas welcome. Testing welcome. Whining to /dev/null or I come after you with a chainsaw. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-cl...@lists.scsys.co.uk - End forwarded message -
Re: takeover request - DBD::SQLite
Hello Steffen et al, thanks for your response. I was not previously aware that Adam had taken this up; no mention of it in any forums I frequent nor on CPAN. But I'm very happy to hear it nonetheless. If Adam is serious about this and wants to organize the effort to keep DBD::SQLite up to date, then I'm quite happy to step back from trying to start my own effort. The main reason I offered to take over or co-maintain back around Jan 12th was because the module seemed to be abandoned and no one else was stepping up. So I'm happy and prefer to join Adam's effort rather than doing a separate one. Adam, I see from the Changes file in your repo that your group's most recent work is later than my announcement, since I announced when SQLite 3.6.8 was new and your repo has 3.6.10, and you've made a number of bug fixes. Please indicate the main forum where your group is discussing this work so I can join it. And I look forward to a CPAN release. Or in helping you do it. Thank you. -- Darren Duncan Steffen Mueller wrote: Hi Darren, hi Matt, Matt, I hope you're well and simply too busy to answer! Darren Duncan wrote: Following up a discussion a couple months ago, Matt Sergeant still hasn't responded to that or any other message from me concerning DBD::SQLite, and so, AFAIK with the community's support, ... I would like to be registered as an official co-maintainer of DBD::SQLite, so I can start release managing it and CPAN will accept my uploads as authorized. I hadn't started work on this before now, but DBD::SQLite has now moved to the front of my queue of un-paid projects (now that Set::Relation 0.9.0 is out), and I plan to start working on it this week or next with a first developer release to CPAN estimated in 2-3 weeks from now and a first normal user release following a few weeks later when early adopters consider it ready. Note that I consider the dbi-dev list to be the official channel for all DBD::SQLite development, so if any of you have any input for this project then please just make it there. Also I have already made an RFC post there earlier today about my initial plans for DBD::SQLite's development. Darren, I've given you co-maintenance permissions via PAUSE. Matt, please note that this is a reversible action in case you severely object! Darren, I only just realized that people have imported the current state of DBD::SQLite into Adam Kennedy's SVN repository at http://svn.ali.as/cpan/trunk/DBD-SQLite/. Without looking at the details, I see that there have been some commits. I guess it would make sense of you joined that effort in order not to duplicate it. I am sure Adam (see CC) will give you access to the repository in no time if you don't have an account already. Best regards, Steffen (for the PAUSE admins)
Re: RFC: developing DBD::SQLite
Cosimo Streppone wrote: In data 27 marzo 2009 alle ore 03:30:10, Darren Duncan ha scritto: So, out of my un-paid projects, my promise to take over release management of DBD::SQLite (from the still incommunicado previous owner) has now come to the front of my queue (now that Set::Relation 0.9.0 is out) Hi Darren, I *seem* to remember, but I might be totally wrong, that ADAMK took over maintainership for DBD::SQLite some months ago. Well that's news to me. And great news if it is true. It also must have been a recent development (I'll look into it) as I didn't see any CPAN releases or announcements. Regarding feedback on DBD::SQLite, give me some time to read all your mail. I first made the proposal around January 12th of this year, quickly following my spreading the news that SQLite 3.6.8 came out with support for nested transactions, and getting responses that DBD::SQLite had all sorts of unresolved bugs and whatever, and seeing for myself it was long since updated. Also Audrey Tang had released SQLite 3.6.1/2 a year ago in amalgamation form, but now neither Audrey nor Matt were doing anything, and I saw no evidence that anyone else was too. So I offered to do it. The only thing I can say right now is that DBD::SQLite rocks for me because it's a direct-from-CPAN install with no hassle, even on Windows. This is also one of the advantages of using the SQLite amalgamation version that sqlite.org provides and Audrey experimentally released. The complicated pre-compilation work is done in advance and so less capable build environments like Windows can then build SQLite without having a pricey tool. Don't know if Adam's version is the amalgamation but I'll look. Anyway, to repeat a prior reply, I've decided not to unbundle the library. -- Darren Duncan
Re: RFC: developing DBD::SQLite
On Thu, 26 Mar 2009 19:30:10 -0700, Darren Duncan wrote: 1. I have no problem with unbundling, but how big a deal is it to keep a pretty recent version bundled for systems that do /not/ have the library installed? In my mixed environment, neither HP-UX nor AIX have it available by default Having said that, I would not object to having to install it myself, but then the Makefile.PL process should point me to what I need to do, so the detection of available files should be close to perfect. The suggested automatic download sounds sane enough. Note that YAML-LibYAML still bundles a (broken) libyaml, but they work rather close with the libyaml people 2. Version support. If you always suggest to download the library, you will be much more confident that the test will pass, as it is likely to be the same version as you tested with. (option 1, option 3, option 2 would be my preferred sequence, as you also suggested) 3. Versions. I don't strongly object, but I see no gain in 3-part versions and version.pm dependency. Certainly for older perls it is a dependency you don't /need/. Note that I have installed version on all my perl's so I don't object to that module per sé, but having evaluated the benefits for myself, I saw no gain in switching. 4. git++ :) > Any thoughts on that matter, or on anything else I raised? As you move from bundled to unbundled, I would really like to have a choice to get the old behaviour through a download. How much do you care about old(er) architectures? I mean, as you will unbundle, you have no control anymore about the portability of the files DBD-SQLite-1.14 on HP-UX 10.20: Using DBI 1.607 (for perl 5.008008 on PA-RISC2.0) cc -c -I. -I/pro/lib/perl5/site_perl/5.8.8/PA-RISC2.0/auto/DBI -Ae +DAportable +Z -z -D_HPUX_SOURCE -Wl,+vnocompatwarnings -I/pro/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 +O2 +Onolimit -DVERSION=\"1.14\" -DXS_VERSION=\"1.14\" +Z "-I/pro/lib/perl5/5.8.8/PA-RISC2.0/CORE" -DSQLITE_CORE -DSQLITE_ENABLE_FTS2 -DNDEBUG=1 -DSQLITE_PTR_SZ=4 -DHAVE_USLEEP=1 -DTHREADSAFE=0 os_unix.c cpp: "os_unix.c", line 2633: error 4036: Can't open include file 'dlfcn.h'. make: *** [os_unix.o] Error 1 No, that system doesn't have it. -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.3, 11.0, and 11.1, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: RFC: developing DBD::SQLite
In data 27 marzo 2009 alle ore 03:30:10, Darren Duncan ha scritto: So, out of my un-paid projects, my promise to take over release management of DBD::SQLite (from the still incommunicado previous owner) has now come to the front of my queue (now that Set::Relation 0.9.0 is out) Hi Darren, I *seem* to remember, but I might be totally wrong, that ADAMK took over maintainership for DBD::SQLite some months ago. Regarding feedback on DBD::SQLite, give me some time to read all your mail. The only thing I can say right now is that DBD::SQLite rocks for me because it's a direct-from-CPAN install with no hassle, even on Windows. -- Cosimo
Re: RFC: developing DBD::SQLite
David, thanks for your quick response. David E. Wheeler wrote: > You *really* need to get Matt to signoff on this, IMHO. I have tried emailing Matt several times without response already. Should I try telephoning him next? For all it looks like, Matt has abandoned the module. If someone knows better, or has been in contact recently, I'd be happy to hear. So following your response, I will eliminate a lot of the change items from my plan. In particular, I will continue to bundle the SQLite library as it has always been done, and won't download anything. I will also not add the version.pm dependency and will continue numbering releases where Matt left off, such as starting at version 1.15 or jumping up a bit and starting at 1.20_01 which should be harmless. In regards to which version to use, I will also leave that behaviour as Matt had it; his version could either use the bundled version or the system version, and I'll leave selecting which to the same mechanism Matt had it, unless the users argue for a change. I think that means the bundled is the default. So then, what I'm planning to do is this then: 1. Enter DBD::SQLite into public version control using Git, with the initial version being the last one Matt published on CPAN, and then I will merge in Audrey Tang's changes that were released as DBD::SQLite::Amalgamation; essentially there is no change but that several dozen SQLite library files are replaced with a single one. 2. Then I'll update the library to the latest one on sqlite.org, and then retest and deal with anything that breaks. 3. Then I'll look at various open RT items and apply various submitted bug fixes, again testing. And I'll accept collaborative fixes from other people such as those made against the version control. 4. Then I'll put an experimental-versioned release on CPAN. In fact, despite the larger sized releases, this probably is actually much less work for me when it comes down to it due to less complexity. I really will just make the minimal changes possible from Matt's version, just to get it to run with the current SQLite library, which will now be the single amalgamation file. Also mainly the driver would just be tested and asserted by me to work with the version of SQLite bundled with it. And if users replace the bundled amalgamation file with a different amalgamation file, generally it'll act as if the replacement was the original, so this isn't really a separate case. Now I know you said prefer system, but to start I'll just leave it the way Matt had it; mind you, if there is a general consensus to change this default, I'll honor it. And my current plans are now back to what they were earlier this year when I proposed co-maintaining the driver, a focus on minimalism, before I became more ambitious in today's first proposal. To conclude, I would be quite happy to not have this responsibility. I am doing this primarily because I want SQLite to continue to succeed in the Perl world and no one is keeping the bindings up to date anymore, despite many people asking for updates. I'm doing it because no one else is. Now if Matt comes out of the shadows and addresses the languishing driver bug reports and updates the library to the new one, and continues to do so, I'm the happiest, but so far he isn't. And my email attempts have failed at a response. So, should I try to phone Matt now? Thank you. -- Darren Duncan
Re: RFC: developing DBD::SQLite
On Mar 26, 2009, at 10:30 PM, Darren Duncan wrote: Hello, So, out of my un-paid projects, my promise to take over release management of DBD::SQLite (from the still incommunicado previous owner) has now come to the front of my queue (now that Set::Relation 0.9.0 is out), so I'm now starting to think about it in detail and get to work over the next week or two. In that vein, the first and only major design change I intend to make right from the start is to stop bundling the SQLite library with the DBI driver and so the driver will have that library as an external dependency. --1. Prefer a system-installed lib, but use the bundled lib if one cannot be found on the system. Don't make this harder for people to use. While one of the selling points of DBD::SQLite versus other DBI drivers in the past was that it came with everything you need, with the advent of a single file "amalgamation" library being provided standard from sqlite.org, as well as the increasing availability of the SQLite library as its own shared system library install, I figure it isn't too difficult now for users to either obtain the library separately or use the one that came with their system, or the DBD::SQLite installer could automatically download it similar to how some other projects download their dependencies (Rakudo Perl 6 can download Parrot for example); so I don't think the ease of use of DBD::SQLite is diminished significantly by it no longer bundling the SQLite library. Don't download it; a lot of times modules are installed where there is no access to the Net. And those libraries that download external dependencies never work very well (see Math::Pari). On the other side, there is a lot of benefit gained from not bundling. For one thing the size of the distribution as well as the source control is cut down significantly, since the DBI driver alone is orders of magnitude smaller. For another thing, occasional needs to update for compatibility aside, DBD::SQLite will always be up to date with the newest SQLite library; users just update the library and possibly recompile the DBD::SQLite they already have. And so DBD::SQLite won't need to be updated as often; it would just need updates to address incompatible changes to the SQLite library, or to fix bugs in or update features specific to DBD::SQLite itself. These are benefits to the developer of the module, not to the end user. I don't find them compelling. Another quasi-change is that DBD::SQLite will be designed to work specifically with the amalgamation version of the source files only, not the pre-amalgamated versions; I say quasi-change since Audrey Tang already did the work to convert DBD::SQLite to work this way, in the separate ::Amalgamation distro. Don't know anything about this. Compatibility-wise, my DBD::SQLite will endeavour to work with all versions of SQLite 3.y.z, though note that only 3.4.0 for which the amalgamation file was a distinct download on sqlite.org (and 3.3.14 or so was the first that amalgamation was a make target). Or more specifically, I only plan to test with the latest SQLite source library available at the time (3.6.11 currently), as well as probably whatever version comes with Mac OS X Leopard. Supporting older versions will happen as I get advocates or testers for them. I also won't explicitly drop support for any Perl or DBI versions that the current DBD::SQLite supports, but I only intend to test it with the latest DBI and Perl 5.8.x+. If you don't test it with other versions, how can you be sure that they're supported? I deal with this with pgTAP, BTW; I have to keep 5 separate PostgreSQL installations around to make sure it works with all of them. You could probably script it to test that it works with n versions of SQLite. That would obviously be an improvement over the current maintenance. A minor change is I will start out with using 3-part versions and have a dependency on version.pm 0.74, which is bundled with Perl 5.10.x and an easy install otherwise. Why? I see no benefit to this, and just imposes yet another inconvenience on users. Now a specific question for you: First assume the new DBD::SQLite can look in at least 3 places for a SQLite library to use, which are: 1. An amalgamation file that the user explicitly put in the distro directory (or that was similarly slipstreamed into a copy of the distro maybe by some OS package manager); 2. A SQLite system shared library that was installed either as part of the OS or later by a user; 3. Go and automatically fetch a copy of the latest amalgamation file from sqlite.org, similarly to how Rakudo Perl 6 can go fetch a copy of its Parrot dependency from the 'net. Now assuming that, changeable config options aside, there is an automatic default order that th
RFC: developing DBD::SQLite
Hello, So, out of my un-paid projects, my promise to take over release management of DBD::SQLite (from the still incommunicado previous owner) has now come to the front of my queue (now that Set::Relation 0.9.0 is out), so I'm now starting to think about it in detail and get to work over the next week or two. In that vein, the first and only major design change I intend to make right from the start is to stop bundling the SQLite library with the DBI driver and so the driver will have that library as an external dependency. While one of the selling points of DBD::SQLite versus other DBI drivers in the past was that it came with everything you need, with the advent of a single file "amalgamation" library being provided standard from sqlite.org, as well as the increasing availability of the SQLite library as its own shared system library install, I figure it isn't too difficult now for users to either obtain the library separately or use the one that came with their system, or the DBD::SQLite installer could automatically download it similar to how some other projects download their dependencies (Rakudo Perl 6 can download Parrot for example); so I don't think the ease of use of DBD::SQLite is diminished significantly by it no longer bundling the SQLite library. On the other side, there is a lot of benefit gained from not bundling. For one thing the size of the distribution as well as the source control is cut down significantly, since the DBI driver alone is orders of magnitude smaller. For another thing, occasional needs to update for compatibility aside, DBD::SQLite will always be up to date with the newest SQLite library; users just update the library and possibly recompile the DBD::SQLite they already have. And so DBD::SQLite won't need to be updated as often; it would just need updates to address incompatible changes to the SQLite library, or to fix bugs in or update features specific to DBD::SQLite itself. Another quasi-change is that DBD::SQLite will be designed to work specifically with the amalgamation version of the source files only, not the pre-amalgamated versions; I say quasi-change since Audrey Tang already did the work to convert DBD::SQLite to work this way, in the separate ::Amalgamation distro. Compatibility-wise, my DBD::SQLite will endeavour to work with all versions of SQLite 3.y.z, though note that only 3.4.0 for which the amalgamation file was a distinct download on sqlite.org (and 3.3.14 or so was the first that amalgamation was a make target). Or more specifically, I only plan to test with the latest SQLite source library available at the time (3.6.11 currently), as well as probably whatever version comes with Mac OS X Leopard. Supporting older versions will happen as I get advocates or testers for them. I also won't explicitly drop support for any Perl or DBI versions that the current DBD::SQLite supports, but I only intend to test it with the latest DBI and Perl 5.8.x+. A minor change is I will start out with using 3-part versions and have a dependency on version.pm 0.74, which is bundled with Perl 5.10.x and an easy install otherwise. Now a specific question for you: First assume the new DBD::SQLite can look in at least 3 places for a SQLite library to use, which are: 1. An amalgamation file that the user explicitly put in the distro directory (or that was similarly slipstreamed into a copy of the distro maybe by some OS package manager); 2. A SQLite system shared library that was installed either as part of the OS or later by a user; 3. Go and automatically fetch a copy of the latest amalgamation file from sqlite.org, similarly to how Rakudo Perl 6 can go fetch a copy of its Parrot dependency from the 'net. Now assuming that, changeable config options aside, there is an automatic default order that these alternate sources will be used by a hands-free CPAN/CPANPLUS/etc install, I ask you what options should be used and in what order? Now I think we probably can all agree that if choice #1 is satisfied (the user explicitly put a file to use in the distro dir or a packager did), then it is clear-cut to try to use that or die trying. What is less clear cut is whether the next automatic default action should be to use an already installed SQLite shared library or whether to download the latest from sqlite.org. I'm thinking that between #2 and #3, that #3 (get the latest) should always be the default choice, and that users have to explicitly override, such as by setting an environment variable, or whatever already happens with DBD::SQLite, to use the system one instead. So in fact the real question then is whether I should stay with the precedent existing with the current DBD::SQLite, which effectively is download from sqlite.org by default, or whether I should change this default. Any thoughts on that matter, or on anything else I raised? And whi
Re: request to become co-maintainer of DBD::SQLite
Erik, Thank you for volunteering, and that help is appreciated. Also, I still haven't heard back from the normal maintainer, so I think I'm going to step up. However, real life has intruded (eg, paying clients want stuff now) so it will still be a few weeks before I begin release-managing DBD::SQLite. I currently estimate mid-March to get into it. -- Darren Duncan Erik Aronesty wrote: 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, I will also do what I can to help, if anyone wants it. Also, is there a repository anywhere? It's not documented in the source or anywhere that I can find.. I usually find it easier submit patches if there's a repository involved. - There are some obvious patches and minor tweaks involving threading that can fix support on Win32. Notably the CLONE method doesn't work on a win32 fork, so a workaround would be to store the threadid along with the handle and compare to the current thread id to see if a clone is needed. (I posted an patch that simply disables testing for cloning on win32, which would probably satisfy 60% of the win32 users at the outset.) - Solaris and Win32 both have problems where the DBD xsi file creation line isn't included in the Makefile. **I think this is a DBI issue... since the code for that is part of DBI's driver implementation, but I haven't actally traced it to the line that is failing to see why. I can do that if anyone wants me too, but my bet is that the DBI devs know about it already, or could take one look at SQLite's Makefile.PL and tell me why it fails or what a good workaround is. Mostly, I'm not too concerned with a lot of the "my system locks up" bugs, as my guess is they are issues that will be addressed in new versions SQLite's, and they are common to embedded databases that run on a mixed-bag of operating systems. But compatibility = usage = support, and that's my primary concern.
Re: request to become co-maintainer of DBD::SQLite
> >> 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, I will also do what I can to help, if anyone wants it. Also, is there a repository anywhere? It's not documented in the source or anywhere that I can find.. I usually find it easier submit patches if there's a repository involved. - There are some obvious patches and minor tweaks involving threading that can fix support on Win32. Notably the CLONE method doesn't work on a win32 fork, so a workaround would be to store the threadid along with the handle and compare to the current thread id to see if a clone is needed. (I posted an patch that simply disables testing for cloning on win32, which would probably satisfy 60% of the win32 users at the outset.) - Solaris and Win32 both have problems where the DBD xsi file creation line isn't included in the Makefile. **I think this is a DBI issue... since the code for that is part of DBI's driver implementation, but I haven't actally traced it to the line that is failing to see why. I can do that if anyone wants me too, but my bet is that the DBI devs know about it already, or could take one look at SQLite's Makefile.PL and tell me why it fails or what a good workaround is. Mostly, I'm not too concerned with a lot of the "my system locks up" bugs, as my guess is they are issues that will be addressed in new versions SQLite's, and they are common to embedded databases that run on a mixed-bag of operating systems. But compatibility = usage = support, and that's my primary concern.
Re: request to become co-maintainer of DBD::SQLite
[[ This message was both posted and mailed: see the "To," "Cc," and "Newsgroups" headers for details. ]] In article <496d6232.4050...@darrenduncan.net>, Darren Duncan wrote: > Hello Matt Sergeant, > > I would like to request your permission or blessing to become an official > co-maintainer of the DBD::SQLite module, which is the defacto standard > binding > for SQLite to Perl. Noted on modu...@perl.org. Just let us know what the outcome is and if you need us to do something to help the transfer. -- brian d foy (one of many PAUSE admins), http://pause.perl.org archives at http://www.xray.mpe.mpg.de/mailing-lists/modules please send all messages back to modu...@perl.org
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
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
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: [Dbix-class] request to become co-maintainer of DBD::SQLite
This is a reply to a post on the dbix-class list. However, if there is going to be ongoing discussion I prefer it happen on the dbi-dev list, since dbi-dev just seems the most on topic, I think. Goro Fuji wrote: Just now I am concidering to maintain DBD::SQLite, and I have ideas about that: (1) to separate SQLite from DBD::SQLite (not to be bundled), which will also separate ploblems of SQLite from those of DBD::SQLite. (2) to make a new module Alien::SQLite (see other Alien::* modules), which will allow different versions of SQLite. (3) to allow "use DBD::SQLite 1.15 -sqlite_version => q(3.6.8)" for testing. What do you think of it? That sounds like it could be a good idea on paper. I'm not sure I know yet the degree of changes it would involve. By default I think I'll start off with the fewest changes, also now most likely using Audrey Tang's amalgamation as the point of departure, but DBD::SQLite could also go the way you say. I think this is an idea best discussed on dbi-dev or if you want to prototype and present your idea there please do so. There are probably other issues to consider that people may bring up. 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
request to become co-maintainer of DBD::SQLite
Hello Matt Sergeant, I would like to request your permission or blessing to become an official co-maintainer of the DBD::SQLite module, which is the defacto standard binding for SQLite to Perl. (Also CC'd are some other concerned parties as FYI; my apologies if I've written too many people. But this message is initially just for response by Matt, though others can write if they feel inclined, but try to keep the recipient list smaller than I just did here. Focus any discussion to dbi-dev@perl.org and modu...@perl.org as appropriate please, the former for what work needs doing and the latter for matters of module maintainership.) P.S. Or if anyone else has the tuits and wants to make a better offer to be a co-maintainer now, please do so. I am interested in the long-term success of SQLite in combination with Perl, and in the short term I am particularly interested in using the latest SQLite 3.6.8 (which adds the extremely important feature of nested transactions) with modern versions of Perl, and I am interested that it would be easy for the large number of other DBD::SQLite users to use this combination as well. I am also concerned with there apparently being a number of significant bugs in DBD::SQLite that have been reported on the RT system, some with patches, and DBD::SQLite hasn't seen new releases in awhile to either address bugs or update the bundled SQLite. A number of people I trust are seeing that this is a serious matter to address, some in the mean-time recommending use of older DBD::SQLite versions, which is itself a problem since automatic CPAN install tools would select the newest versions, and access to newer SQLite library features is missing. Now I would of course be happiest if you had the time and motivation to bring your project up to date and address its bugs. But otherwise I would like to offer you an out, and take on this responsibility myself, either alone or with partners such as yourself or other concerned parties that want to help. If you agree, then please say the word to modu...@perl.org. My CPAN account ID is DUNCAND. To summarize, this is my intention in the short term: 1. Release a new version every time there is a SQLite core library release. 2. Make only the most minimal changes to DBD::SQLite itself, to ensure that reported bugs are fixed and that it compiles on modern systems and passes its own test suite on the same. There won't be any feature additions or architectural changes initially, except where such may be highly demanded and simple. The priorities here are stability and correctness plus easy access to all the SQLite library's native features, and minimal additional features. 3. All initial releases will have version numbers ending in _NN that mark them as developer releases, so the community can test them before they become what the CPAN tools install by default. 4. Perhaps follow what Audrey Tang started and use the official amalgamated pre-compiled source files rather than the original-original source code, so users with less capable build environments can handle it. Though in the short term this will depend on which version I can get to work with fewer problems on my own machine (Mac OS X Leopard). 5. I may use an older DBD::SQLite than the current one, such as 1.12, as an initial point of departure, if doing so makes for a more trouble-free solution. 6. I will have this in a public GIT source repository and I will regularly seek feedback, help, patches, testing, etc from the user community that have a stake in this working. 7. I am assuming until corrected that the primary discussion forum for people to discuss actual work to do and patches etc for DBD::SQLite is dbi-...@perl.org. Some caveats: 1. I have very little C-fu right now and won't be able to do much in the short term besides update the SQLite source files, and apply third-party patches to the C, and make more involved fixes to the portions written in Perl. 2. It will probably be several weeks before my first release, partly because I am busy with other tasks and I also need time for feedback and discussion. 3. All my releases should be considered experimental until further notice, after a significant body of users has put them through the ringer and considered them GA quality. 4. I *will* require third parties to submit patches to bugs in the C code in order for many relevant problems to be fixed. I may be able to fix some problems myself, but otherwise I call it a division of labour, and my part is mainly about applying patches and doing the releases; others can do a lot of the actual fix patch making. Generally speaking, the bugs that get fixed are the ones people send me patches for. 5. In general I will not ever be working with blead of the core SQLite library, only its public releases, which have a thorough test suite of their own. 6. One of my first c
DBD::SQLite problem with re-using a $sth: "selectrow_array failed: not an error(21)"
Hi Mr. Sergeant! (and the members of the DBI-dev mailing list).
I encountered a problem in DBD::SQLite: (version 1.09)
http://search.cpan.org/dist/DBD-SQLite/
It is demonstrated by the following two scripts:
<<<
# Statement-Reuse-Prepare.pl - run it once.
use DBI;
$db_name = "foo.sqlite";
unlink($db_name);
my $test_dsn = "DBI:SQLite:dbname=$db_name";
my $test_user = '';
my $test_password = '';
my $dbh = DBI->connect($test_dsn, $test_user,
$test_password);
foreach my $stmt (
qq{CREATE TABLE testaa (id INTEGER, name CHAR (64));},
qq{INSERT INTO "testaa" VALUES(1, 'Alligator Descartes');},
qq{INSERT INTO "testaa" VALUES(NULL, 'NULL-valued id');},
qq{INSERT INTO "testaa" VALUES(2, 'Gary Shea');},
)
{
$dbh->do($stmt);
}
>>>
And:
<<<<<<<
# Statement-Reuse.pl - run it after the -Prepare script to demonstrate
# the problem
use strict;
use warnings;
use DBI;
my $test_dsn = "DBI:SQLite:dbname=foo.sqlite";
my $test_user = '';
my $test_password = '';
my $test_table = "testaa";
sub Test
{
return @_;
}
my $dbh = DBI->connect($test_dsn, $test_user,
$test_password);
{
my (@ret);
my $test_query = "SELECT name FROM $test_table WHERE id = ?";
my $sth = $dbh->prepare_cached($test_query);
print "DEBUG \$sth == $sth\n";
print "DEBUG \\\$sth == " . (\$sth) . "\n";
@ret = $dbh->selectrow_array($sth, undef, 1);
Test ($ret[0] eq "Alligator Descartes")
or printf("selectrow_array returned a wrong result: %s\n", $ret[0]);
$sth = $dbh->prepare_cached($test_query);
@ret = $dbh->selectrow_array($sth, undef, 1);
Test ($ret[0] eq "Alligator Descartes")
or printf("selectrow_array returned a wrong result: %s\n", $ret[0]);
@ret = $dbh->selectrow_array($sth, undef, 2);
Test ($ret[0] eq "Gary Shea")
or printf("selectrow_array returned a wrong result: %s\n", $ret[0]);
$sth = $dbh->prepare_cached($test_query);
@ret = $dbh->selectrow_array($sth, undef, 2);
Test ($ret[0] eq "Gary Shea")
or printf("selectrow_array returned a wrong result: %s\n", $ret[0]);
}
>>>>>>>
The bug is also reported here:
http://www.issociate.de/board/post/242705/DBD::SQLite_1.09_dies_if_select_returns_0_rows.html
(Short URL - http://xrl.us/hdor )
After delving into the code and trying to solve it, I reached the following
conclusions:
1. The following lines (319 and on) in dbdimp.c in the DBD-SQLite distro, are
doing the wrong thing:
psv = hv_fetch((HV*)SvRV(sth), "Statement", 9, 0);
statement = (psv && SvOK(*psv)) ? SvPV_nolen(*psv) : "";
This is because there isn't a "Statement" key in the Hashref of the statement
handle (sth). As a result the variable "statement" is assigned the empty
string, and it is compiled as such.
2. There seems to be some assignment to the "Statement" key in the core
DBI module but it doesn't take effect there.
I tried to correct everything using this patch:
<<<<<<<<<<<<<<<
Index: dbdimp.c
===
--- dbdimp.c(revision 18)
+++ dbdimp.c(revision 19)
@@ -259,6 +259,10 @@
imp_sth->retval = SQLITE_OK;
imp_sth->params = newAV();
+/* Put the "Statement" key manually so it can later be referred to by
+ * sqlite_st_execute */
+hv_store((HV*)SvRV(sth), "Statement", 9, newSVpv(statement, 0), 0);
+
if ((retval = sqlite3_prepare(imp_dbh->db, statement, 0,
&(imp_sth->stmt), &extra))
!= SQLITE_OK)
{
@@ -313,6 +317,8 @@
if (imp_sth->nrow >= 0) {
SV **psv;
char *statement;
+psv = hv_fetch((HV*)SvRV(sth), "Statement", 9, 0);
+statement = (psv && SvOK(*psv)) ? SvPV_nolen(*psv) : "";
if (!sqlite_st_finish(sth, imp_sth)) {
return -1;
}
>>>>>>>>>>>>>>>
But it doesn't work from some reason. Note that I'm not very familiar with
the Perl 5 C API and the perl 5 internals so I can know exactly what to
do. I read "Extending and Embedding Perl" once upon a time, but don't recall
too much from it, or have it handy.
Can anyone help me fix this problem? I spent an entire day trying to fix it
myself. I need it because I'm using DBD::SQLite to test a module I wrote (for
work), and I'd rather be working on the core production code.
Regards,
Shlomi Fish
-
Shlomi Fish [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/
Tcl is LISP on drugs. Using strings instead of S-expressions for closures
is Evil with one of those gigantic E's you can find at the beginning of
paragraphs.
fixing the type info for DBD::SQLite
I posted this as a bug against DBD::SQLite but haven't heard back. I
would be happy to fix this myself
This program shows that DBD::SQLite returns unusual type info. I would
appreciate any pointers on where to go to fix this. It looks like one
just needs to write a mapper of some sort:
my %type_conv =
( 'CHAR' => 1,
'INT' => 4
);
But the problem is figuring out how DBD::SQLite services the
$sth->FETCH('TYPE') call from DBI.
~/hacks/dbirs $ perl tryselect.pl sqlite
INT CHAR(20) INT CHAR(20) at tryselect.pl line 26.
~/hacks/dbirs $ perl tryselect.pl pg
4 1 4 1 at tryselect.pl line 26.
~/hacks/dbirs $ cat tryselect.pl
use DBI;
use DBD::SQLite;
my %dsn =
(
sqlite => 'dbi:SQLite:test.db',
pg => 'dbi:Pg:dbname=test'
)
;
my $dsn_key = shift or die 'must supply dsn key';
my $dsn = $dsn{$dsn_key} or die "$dsn_key not found";
my $dbh = DBI->connect
($dsn, undef, undef, { RaiseError => 1 } );
my $tbl = 'dbixrs1';
my $sql = "SELECT * FROM $tbl WHERE 1=0" ;
$sth = $dbh->prepare($sql);
$sth->execute;
my $type = $sth->FETCH('TYPE');
warn "@$type";
Re: DBD::SQLite
On Tue, Feb 19, 2002 at 10:41:37AM +0100, H.Merijn Brand wrote: > > > > > > But have these functions not implemented? > > > - Place holders > > > > Yes, in CVS, but SQLite doesn't support them, so it uses the hackish > > method of splitting up the SQL on ? and re-joining it for execution with > > the values in place. Yucky. > > I admid I've been spending not enough time on the DB[ID] part of my perl > activities, but didn't someone make some generic XS part for this on a request > of Tim? IIRC 'bout 6 month ago. A quick browse through the messages I saved > regarding DBI didn't show anything though. Try use DBI qw(:preparse_flags); $sql = $dbh->preparse($sql, DBIpp_ph_sp, DBIpp_ph_qm); in the latest DBI. That should read the input sql containing '?' placeholders and return it in a form that can be used for sprintf. It can do rather more that that, and will do much more in future. See t/preparse.t for some tests. It's all a bit new (and undocumented) and currently there's no way to get other info back like how many placeholders there are. But after the above you could use a regex that counts %s's that don't have a preceding %. Tim.
Re: DBD::SQLite
On Tue 19 Feb 2002 23:10, "Sterin, Ilya" <[EMAIL PROTECTED]> wrote: > Oh, yes they do:-) DBD::Oracle version (earlier) had this problem. I > believe even some DBD::MySQL version had it (or still have it). I've ran > into this problem numerous times working with different version that the > client had installed. I think it has to do with dealocating the handles > before the actual disconnect, therefore in your code if you just undef the > handles, it will eliminate this error message as well. or put the whole lot in braces to create a local scope so it is destroyed automatically I *never* disconnect, so the handles are destroyed on leave of scope /before/ the disconnect happens. -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.7.1 & 630 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.022 &/| DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
RE: DBD::SQLite
Oh, yes they do:-) DBD::Oracle version (earlier) had this problem. I believe even some DBD::MySQL version had it (or still have it). I've ran into this problem numerous times working with different version that the client had installed. I think it has to do with dealocating the handles before the actual disconnect, therefore in your code if you just undef the handles, it will eliminate this error message as well. Ilya -Original Message- From: Matt Sergeant To: KAWAI,Takanori Cc: [EMAIL PROTECTED] Sent: 2/19/02 3:04 PM Subject: Re: DBD::SQLite On Wed, 20 Feb 2002, KAWAI,Takanori wrote: > - Original Message - > From: "Matt Sergeant" <[EMAIL PROTECTED]> > To: "KAWAI,Takanori" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Tuesday, February 19, 2002 10:16 PM > Subject: Re: DBD::SQLite > > (snip) > > > > OK, new release out - http://axkit.org/download/DBD-SQLite-0.03.tar.gz > > > Well, it occurs "Segmentation fault" with 2 placeholders. > > > A placeholder not occurs error but it makes warnings. > > > > Fixed. Just s/0.03/0.04/; > Great! It works fine. > Thank you for your fast fix. > And I've heard that it also works on Windows. > #Sorry I just heard. > > I might be nagging ... > 1) Active property with INSERT statement > When I execute an "INSERT" statement, statement handle seems > to be Active. I feel strange about this. Yes, I wasn't sure how to fix it. I'll look into it a bit further though. > 2) test.pl > test.pl ends up this line: > > Issuing rollback() for database handle being DESTROY'd without > explicit disconnect(). > > To avoid this line, add "$dbh->disconnect;" at the end of test.pl. Other DBD drivers don't seem to report this, and I have no idea why not. If anyone knows why I'd love to know. -- <:->Get a smart net
Re: DBD::SQLite
On Wed, 20 Feb 2002, KAWAI,Takanori wrote: > - Original Message - > From: "Matt Sergeant" <[EMAIL PROTECTED]> > To: "KAWAI,Takanori" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Tuesday, February 19, 2002 10:16 PM > Subject: Re: DBD::SQLite > > (snip) > > > > OK, new release out - http://axkit.org/download/DBD-SQLite-0.03.tar.gz > > > Well, it occurs "Segmentation fault" with 2 placeholders. > > > A placeholder not occurs error but it makes warnings. > > > > Fixed. Just s/0.03/0.04/; > Great! It works fine. > Thank you for your fast fix. > And I've heard that it also works on Windows. > #Sorry I just heard. > > I might be nagging ... > 1) Active property with INSERT statement > When I execute an "INSERT" statement, statement handle seems > to be Active. I feel strange about this. Yes, I wasn't sure how to fix it. I'll look into it a bit further though. > 2) test.pl > test.pl ends up this line: > > Issuing rollback() for database handle being DESTROY'd without > explicit disconnect(). > > To avoid this line, add "$dbh->disconnect;" at the end of test.pl. Other DBD drivers don't seem to report this, and I have no idea why not. If anyone knows why I'd love to know. -- <:->Get a smart net
Re: DBD::SQLite
- Original Message -
From: "Matt Sergeant" <[EMAIL PROTECTED]>
To: "KAWAI,Takanori" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, February 19, 2002 10:16 PM
Subject: Re: DBD::SQLite
(snip)
> > > OK, new release out - http://axkit.org/download/DBD-SQLite-0.03.tar.gz
> > Well, it occurs "Segmentation fault" with 2 placeholders.
> > A placeholder not occurs error but it makes warnings.
>
> Fixed. Just s/0.03/0.04/;
Great! It works fine.
Thank you for your fast fix.
And I've heard that it also works on Windows.
#Sorry I just heard.
I might be nagging ...
1) Active property with INSERT statement
When I execute an "INSERT" statement, statement handle seems
to be Active. I feel strange about this.
my $sth = $dbh->prepare('INSERT INTO MST VALUES(?, ?)');
$sth->execute(1, 'ITEM1');
$sth->execute(2, 'ITEM2');
$sth->execute(3, 'ITEM3');
$dbh->commit;
print "ACTIVE?:", $sth->{Active}, "\n";
$sth->finish();
Active (boolean, read-only)
True if the handle object is "active". This is rarely used in applications.
The exact meaning of active is somewhat vague at the moment.
For a database handle it typically means that the handle is connected
to a database ($dbh->disconnect sets Active off). For a statement
handle it typically means that the handle is a SELECT that may have
more data to fetch. (Fetching all the data or calling $sth->finish sets
Active off.)
2) test.pl
test.pl ends up this line:
Issuing rollback() for database handle being DESTROY'd without
explicit disconnect().
To avoid this line, add "$dbh->disconnect;" at the end of test.pl.
Anyway, Congratulations.
That must be a great tool to give us much more fun :-).
=
Kawai, Takanori(Hippo2000)
Mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
http://member.nifty.ne.jp/hippo2000
==
Re: ANNOUNCE: DBD::SQLite
Matt Sergeant wrote: > I've just uploaded the first public version of DBD::SQLite to CPAN. Again, congratulations. It looks like a fine addition to the DBDs. I have a bit of concern about your comparisons with DBD::CSV though, please see my comments below which widen the field of comparison a bit. > DBD::SQLite is a DBD driver that contains the database engine in the > driver. That means you don't need to install anything else In this it is similar to DBD::CSV, DBD::AnyData, DBD::Sprite, and DBD::Xbase -- all contain their own database engines within the drivers and don't require additional RDBMS installation. DBD::SQLite requires a C compiler or a binary version of the module, while the others do not. > uses > a single disk file for the whole database. Which can also be true of some of the other drivers (e.g. AnyData::Format::XML). It should also be mentioned that DBD::SQLite, unlike most of the other mentioned DBDs, stores its data in a machine-but-not-human readable format. > It's a type-less database, much like CSV files, but you can specify types > when you create the tables (no doubt this will be supported better in the > future). > It supports atomic commit and rollback - something you can't do with CSV. Types, and commit and rollback are in the works for DBD::CSV and DBD::AnyData, I don't know about the situation with the other engine-in-themselves drivers. It also seems to me that for users to make an informed choice, they will need a comparison between SQLite and things like MySQL and PostgreSQL. If they have existing data in various formats (Fixed Length, CSV, etc.) they will either use things like DBD::CSV meant to work with human readable formats or they will convert everything to some machine-readable format such as used by SQLite, MySQL, PG, and the other RDBMSs. So it seems more relevant to compare SQLite with that group rather than with the DBDs supporting human readable formats. -- Jeff
Re: DBD::SQLite
On Tue, 19 Feb 2002, KAWAI,Takanori wrote: > > - Original Message - > From: "Matt Sergeant" <[EMAIL PROTECTED]> > To: "KAWAI,Takanori" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Tuesday, February 19, 2002 6:45 PM > Subject: Re: DBD::SQLite > > > > On Tue, 19 Feb 2002, KAWAI,Takanori wrote: > (snip) > > > It works almost fine. > > > But unfortunately, it makes a error when I call execute twice on the > > > same statement handle. > > > > OK, new release out - http://axkit.org/download/DBD-SQLite-0.03.tar.gz > Well, it occurs "Segmentation fault" with 2 placeholders. > A placeholder not occurs error but it makes warnings. Fixed. Just s/0.03/0.04/; -- Matt. <:->Get a smart net
Re: DBD::SQLite
- Original Message -
From: "Matt Sergeant" <[EMAIL PROTECTED]>
To: "KAWAI,Takanori" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, February 19, 2002 6:45 PM
Subject: Re: DBD::SQLite
> On Tue, 19 Feb 2002, KAWAI,Takanori wrote:
(snip)
> > It works almost fine.
> > But unfortunately, it makes a error when I call execute twice on the
> > same statement handle.
>
> OK, new release out - http://axkit.org/download/DBD-SQLite-0.03.tar.gz
Well, it occurs "Segmentation fault" with 2 placeholders.
A placeholder not occurs error but it makes warnings.
[Script]
use strict;
use DBI;
unlink "foo";
my $dbh = DBI->connect("dbi:SQLite:dbname=foo", "", "",
{AutoCommit => 0, RaiseError => 1});
$dbh->do("CREATE TABLE MST (id, lbl)");
$dbh->do("CREATE TABLE TRN (no, id, qty)");
my $sth1 = $dbh->prepare(q{INSERT INTO MST VALUES(0, ?)});
$sth1->trace(9);
$sth1->execute('ITEM2');
my $sth2 = $dbh->prepare(q{INSERT INTO MST VALUES(?, ?)});
$sth2->trace(9);
$sth2->execute(2, 'ITEM2');
$dbh->rollback;
$dbh->disconnect;
[kawait@lins t]$ perl -w t1.pl
DBI::st=HASH(0x8181a64) trace level set to 9 in DBI 1.20-nothread
-> execute for DBD::SQLite::st (DBI::st=HASH(0x8116fa4)~0x8181a64
'ITEM2')
Use of uninitialized value at t1.pl line 10.
Use of uninitialized value at t1.pl line 10.
<- execute= -1 at t1.pl line 10
DBI::st=HASH(0x8181a28) trace level set to 9 in DBI 1.20-nothread
-> execute for DBD::SQLite::st (DBI::st=HASH(0x8125918)~0x8181a28 2
'ITEM2')
Use of uninitialized value at t1.pl line 13.
Segmentation fault (core dumped)
==
Kawai, Takanori(Hippo2000)
Mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
http://member.nifty.ne.jp/hippo2000
==
Re: DBD::SQLite
On Tue, 19 Feb 2002, H.Merijn Brand wrote: > On Tue 19 Feb 2002 08:12, Matt Sergeant <[EMAIL PROTECTED]> wrote: > > On Tue, 19 Feb 2002, KAWAI,Takanori wrote: > > > On Tue, 19 Feb 2002 04:29, Matt Sergeant" <[EMAIL PROTECTED]> wrote: > > > > I've finished my first stab at DBD::SQLite. > > > > > > > > It's a simple driver for small needs databases, such as when you want > > > > something to ship with a product to demo it, or when DBD::CSV isn't fast > > > > enough, or when MySQL is too much. > > > (snip) > > > > So, please if you get chance, download it from > > > > http://axkit.org/download/DBD-SQLite-0.01.tar.gz, and compile it and play > > > > with it. No docs, just a few tests. Let me know how you get on! > > > GREAT! COOL!! WONDERFUL!!! > > > #sorry for my poor English. > > > > > > It works fine on my Linux box. > > > It seems that has no problem with Japanese string :-). > > > > > > But have these functions not implemented? > > > - Place holders > > > > Yes, in CVS, but SQLite doesn't support them, so it uses the hackish > > method of splitting up the SQL on ? and re-joining it for execution with > > the values in place. Yucky. > > I admid I've been spending not enough time on the DB[ID] part of my perl > activities, but didn't someone make some generic XS part for this on a request > of Tim? IIRC 'bout 6 month ago. A quick browse through the messages I saved > regarding DBI didn't show anything though. I can't find anything in the header files, but it sure would be nice ;-) I'm fairly certain my parsing will be broken in numerous ways (since I had to do it differently to Pg, which was the only driver I had access to when I wrote it), so I just wrote a naive parser. -- <:->Get a smart net
Re: DBD::SQLite
On Tue, 19 Feb 2002, KAWAI,Takanori wrote: > Thank you for your fast fix. No, thank *you* for testing it ;-) > It works almost fine. > But unfortunately, it makes a error when I call execute twice on the > same statement handle. OK, new release out - http://axkit.org/download/DBD-SQLite-0.03.tar.gz -- <:->Get a smart net
Re: DBD::SQLite
On Tue 19 Feb 2002 08:12, Matt Sergeant <[EMAIL PROTECTED]> wrote: > On Tue, 19 Feb 2002, KAWAI,Takanori wrote: > > On Tue, 19 Feb 2002 04:29, Matt Sergeant" <[EMAIL PROTECTED]> wrote: > > > I've finished my first stab at DBD::SQLite. > > > > > > It's a simple driver for small needs databases, such as when you want > > > something to ship with a product to demo it, or when DBD::CSV isn't fast > > > enough, or when MySQL is too much. > > (snip) > > > So, please if you get chance, download it from > > > http://axkit.org/download/DBD-SQLite-0.01.tar.gz, and compile it and play > > > with it. No docs, just a few tests. Let me know how you get on! > > GREAT! COOL!! WONDERFUL!!! > > #sorry for my poor English. > > > > It works fine on my Linux box. > > It seems that has no problem with Japanese string :-). > > > > But have these functions not implemented? > > - Place holders > > Yes, in CVS, but SQLite doesn't support them, so it uses the hackish > method of splitting up the SQL on ? and re-joining it for execution with > the values in place. Yucky. I admid I've been spending not enough time on the DB[ID] part of my perl activities, but didn't someone make some generic XS part for this on a request of Tim? IIRC 'bout 6 month ago. A quick browse through the messages I saved regarding DBI didn't show anything though. > > - Transaction support with $dbh->commit(), $dbh->rollback() > > Not yet. -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.7.1 & 630 on HP-UX 10.20 & 11.00, AIX 4.2, AIX 4.3, WinNT 4, Win2K pro & WinCE 2.11 often with Tk800.022 &/| DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: DBD::SQLite
- Original Message -
From: "Matt Sergeant" <[EMAIL PROTECTED]>
To: "KAWAI,Takanori" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, February 19, 2002 5:18 PM
Subject: Re: DBD::SQLite
> On Tue, 19 Feb 2002, KAWAI,Takanori wrote:
>
> > - Original Message -
> > From: "Matt Sergeant" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Tuesday, February 19, 2002 4:29 AM
> > Subject: DBD::SQLite
> >
(snip)
> > But have these functions not implemented?
> > - Place holders
> > - Transaction support with $dbh->commit(), $dbh->rollback()
>
> OK, both fixed and uploaded as 0.02:
>
> http://axkit.org/download/DBD-SQLite-0.02.tar.gz
>
> Let me know how you get on.
Thank you for your fast fix.
It works almost fine.
But unfortunately, it makes a error when I call execute twice on the
same statement handle.
[sample]
use strict;
use DBI;
unlink "foo";
my $dbh = DBI->connect("dbi:SQLite:dbname=foo", "", "",
{AutoCommit => 0, RaiseError => 1});
$dbh->do("CREATE TABLE MST (id, lbl)");
$dbh->do("CREATE TABLE TRN (no, id, qty)");
my $sth = $dbh->prepare('INSERT INTO MST VALUES(?, ?)');
$sth->trace(9);
$sth->execute(2, 'ITEM2'); #works fine
$sth->execute(3, 'ITEM3'); #makes some trouble(?)
$dbh->rollback;
$dbh->disconnect;
[Result]
[kawait@lins t]$ perl -w t1.pl
DBI::st=HASH(0x8181ad4) trace level set to 9 in DBI 1.20-nothread
-> execute for DBD::SQLite::st (DBI::st=HASH(0x811df44)~0x8181ad4 2
'ITEM2')
<- execute= '0E0' at t1.pl line 10
-> execute for DBD::SQLite::st (DBI::st=HASH(0x811df44)~0x8181ad4 3
'ITEM3')
Modification of a read-only value attempted at t1.pl line 11.
-> DESTROY for DBD::SQLite::st (DBI::st=HASH(0x8181ad4)~INNER)
<- DESTROY= undef
Issuing rollback() for database handle being DESTROY'd without explicit
disconne
ct().
Attempt to free unreferenced scalar.
==
Kawai, Takanori(Hippo2000)
Mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
http://member.nifty.ne.jp/hippo2000
==
Re: DBD::SQLite
On Tue, 19 Feb 2002, KAWAI,Takanori wrote: > - Original Message - > From: "Matt Sergeant" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, February 19, 2002 4:29 AM > Subject: DBD::SQLite > > > > I've finished my first stab at DBD::SQLite. > > > > It's a simple driver for small needs databases, such as when you want > > something to ship with a product to demo it, or when DBD::CSV isn't fast > > enough, or when MySQL is too much. > (snip) > > So, please if you get chance, download it from > > http://axkit.org/download/DBD-SQLite-0.01.tar.gz, and compile it and play > > with it. No docs, just a few tests. Let me know how you get on! > GREAT! COOL!! WONDERFUL!!! > #sorry for my poor English. > > It works fine on my Linux box. > It seems that has no problem with Japanese string :-). > > But have these functions not implemented? > - Place holders > - Transaction support with $dbh->commit(), $dbh->rollback() OK, both fixed and uploaded as 0.02: http://axkit.org/download/DBD-SQLite-0.02.tar.gz Let me know how you get on. -- <:->Get a smart net
Re: DBD::SQLite
On 18 Feb 2002, Jeff Zucker wrote: > Matt Sergeant wrote: > > > > Some benchmarks: > > > > First DBD::CSV latest from CPAN: > > > > Using /root/.cpan/build/DBD-CSV-0.2001/blib > > The relevant thing for the speed of DBD-CSV is the version of > SQL::Statement you are using. If you have the newer perl version > (version 1.002) , I have only recently begun working on optimization. A > more reliable speed test will be with using the older XS version > (version 0.1021). This was 0.1021 of SQL::Statement. > I would also be very interested to hear other comparisons than speed. Yeah, I'd like to get it all working first ;-) One area I expect it to slow down on is large result sets, simply because of the aforementioned problem with how SQLite deals with results. However it's not tragical, as it's just a char** I have to loop over (though it frustratingly isn't null terminated!). > It sounds great. I'll try it as soon as I can. Congrats! Thanks! It was actually easier than I thought it would be, though of course SQLite did the hard work for me. -- <:->Get a smart net
Re: DBD::SQLite
On Tue, 19 Feb 2002, KAWAI,Takanori wrote: > - Original Message - > From: "Matt Sergeant" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, February 19, 2002 4:29 AM > Subject: DBD::SQLite > > > > I've finished my first stab at DBD::SQLite. > > > > It's a simple driver for small needs databases, such as when you want > > something to ship with a product to demo it, or when DBD::CSV isn't fast > > enough, or when MySQL is too much. > (snip) > > So, please if you get chance, download it from > > http://axkit.org/download/DBD-SQLite-0.01.tar.gz, and compile it and play > > with it. No docs, just a few tests. Let me know how you get on! > GREAT! COOL!! WONDERFUL!!! > #sorry for my poor English. > > It works fine on my Linux box. > It seems that has no problem with Japanese string :-). > > But have these functions not implemented? > - Place holders Yes, in CVS, but SQLite doesn't support them, so it uses the hackish method of splitting up the SQL on ? and re-joining it for execution with the values in place. Yucky. > - Transaction support with $dbh->commit(), $dbh->rollback() Not yet. -- <:->Get a smart net
Re: DBD::SQLite
- Original Message -
From: "Matt Sergeant" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, February 19, 2002 4:29 AM
Subject: DBD::SQLite
> I've finished my first stab at DBD::SQLite.
>
> It's a simple driver for small needs databases, such as when you want
> something to ship with a product to demo it, or when DBD::CSV isn't fast
> enough, or when MySQL is too much.
(snip)
> So, please if you get chance, download it from
> http://axkit.org/download/DBD-SQLite-0.01.tar.gz, and compile it and play
> with it. No docs, just a few tests. Let me know how you get on!
GREAT! COOL!! WONDERFUL!!!
#sorry for my poor English.
It works fine on my Linux box.
It seems that has no problem with Japanese string :-).
But have these functions not implemented?
- Place holders
- Transaction support with $dbh->commit(), $dbh->rollback()
I could not find out how to work these functions.
[Script]
use strict;
use DBI;
my $dbh = DBI->connect("dbi:SQLite:dbname=foo", "", "",
{AutoCommit => 0, RaiseError => 1});
$dbh->do("CREATE TABLE MST (id, lbl)");
$dbh->do("CREATE TABLE TRN (no, id, qty)");
$dbh->commit; #not work?
$dbh->do("INSERT INTO MST VALUES(1, 'ITEM1')");
$dbh->do("INSERT INTO MST VALUES(2, 'ITEM2')");
$dbh->do("INSERT INTO MST VALUES(3, 'ITEM3')");
$dbh->do("INSERT INTO TRN VALUES('A', 1, 5)");
$dbh->do("INSERT INTO TRN VALUES('B', 2, 2)");
$dbh->do("INSERT INTO TRN VALUES('C', 1, 4)");
$dbh->do("INSERT INTO TRN VALUES('D', 3, 3)");
$dbh->rollback; #not work?
my $sth = $dbh->prepare(
"SELECT TRN.id AS ID, MST.LBL AS TITLE,
SUM(qty) AS TOTAL FROM TRN,MST
WHERE TRN.ID = MST.ID
GROUP BY TRN.ID ORDER BY TRN.ID DESC");
$sth->execute();
my $names = $sth->{NAME};
print(join(', ', @$names), "\n");
while(my $raD = $sth->fetchrow_arrayref()) {
print join(":", @$raD), "\n";
}
$sth->finish;
$dbh->disconnect;
[Result]
ID, TITLE, TOTAL
3:ITEM3:3
2:ITEM2:2
1:ITEM1:9
==
Kawai, Takanori(Hippo2000)
Mail: [EMAIL PROTECTED] [EMAIL PROTECTED]
http://member.nifty.ne.jp/hippo2000
==
Re: DBD::SQLite
Matt Sergeant wrote: > > Some benchmarks: > > First DBD::CSV latest from CPAN: > > Using /root/.cpan/build/DBD-CSV-0.2001/blib The relevant thing for the speed of DBD-CSV is the version of SQL::Statement you are using. If you have the newer perl version (version 1.002) , I have only recently begun working on optimization. A more reliable speed test will be with using the older XS version (version 0.1021). I would also be very interested to hear other comparisons than speed. It sounds great. I'll try it as soon as I can. Congrats! -- Jeff (current maintainer of SQL::Statement and DBD::CSV and DBD::AnyData)
Re: DBD::SQLite
Some benchmarks: First DBD::CSV latest from CPAN: Using /root/.cpan/build/DBD-CSV-0.2001/blib Testing empty loop speed ... 10 iterations in 0.2 cpu+sys seconds (624999 per sec) Testing connect/disconnect speed ... 2000 connections in 2.4 cpu+sys seconds (840 per sec) Testing CREATE/DROP TABLE speed ... 500 files in 3.7 cpu+sys seconds (135 per sec) Testing INSERT speed ... 500 rows in 2.1 cpu+sys seconds (240 per sec) Testing SELECT speed ... 100 single rows in 12.0 cpu+sys seconds (8.3 per sec) Testing SELECT speed (multiple rows) ... 100 times 100 rows in 13.4 cpu+sys seconds (7.5 per sec) Now DBD::SQLite 0.02, not released yet: Using /home/matt/DBD-SQLite/blib Testing empty loop speed ... 10 iterations in 0.2 cpu+sys seconds (625000 per sec) Testing connect/disconnect speed ... 2000 connections in 3.6 cpu+sys seconds (552 per sec) Testing CREATE/DROP TABLE speed ... 500 files in 1.6 cpu+sys seconds (320 per sec) Testing INSERT speed ... 500 rows in 0.8 cpu+sys seconds (595 per sec) Testing SELECT speed ... 100 single rows in 0.4 cpu+sys seconds (227.3 per sec) Testing SELECT speed (multiple rows) ... 100 times 100 rows in 0.8 cpu+sys seconds (131.6 per sec) Issuing rollback() for database handle being DESTROY'd without explicit disconnect(). Anyone know how you "fix" that last thing? -- <:->Get a smart net
DBD::SQLite
I've finished my first stab at DBD::SQLite. It's a simple driver for small needs databases, such as when you want something to ship with a product to demo it, or when DBD::CSV isn't fast enough, or when MySQL is too much. It includes the entire transaction capable RDBMS code in the DBD driver, and writes a database to a single file, which many will consider nicer than multiple CSV files to emulate multiple tables. The source code for sqlite is public domain, and downloaded from http://www.hwaci.com/sw/sqlite/ Anyway, this is my first hack at a DBD driver, so it's likely buggy, leaky, etc. But seems to work for the simple selects I've run on it so far. I've done no optimization, no performance tests, or anything. I literally hacked this together today for fun. And I'm not particularly looking to maintain it unless there's really strong interest in it, and even then I'd rather someone offered to take it over. So, please if you get chance, download it from http://axkit.org/download/DBD-SQLite-0.01.tar.gz, and compile it and play with it. No docs, just a few tests. Let me know how you get on! -- <:->Get a smart net
