Re: [DBD-SQLite] test DBD::SQLite 1.26_05 - foreign keys!
I'll try to remember that policy when I next make an announcement. Meanwhile, that line was from MST in his DBD::SQLite announcement back in Spring, and it seemed reasonable to continue. And Adam, thank you for being so prompt with the release. -- Darren Duncan Adam Kennedy wrote: Please note the following correction to the announcement. Whining is also welcome. :) Adam K 2009/10/15 Darren Duncan dar...@darrenduncan.net: Patches welcome. Ideas welcome. Testing welcome. Whining to /dev/null. ___ DBD-SQLite mailing list DBD-SQLite@lists.scsys.co.uk http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
[DBD-SQLite] [Fwd: Re: test DBD::SQLite 1.26_05 - foreign keys!]
Original Message Subject: Re: test DBD::SQLite 1.26_05 - foreign keys! Date: Thu, 15 Oct 2009 10:06:51 -0400 From: John Siracusa sirac...@gmail.com Reply-To: rose-db-obj...@googlegroups.com To: rose-db-obj...@googlegroups.com References: 4ad6c3a7.5080...@darrenduncan.net On Thu, Oct 15, 2009 at 2:39 AM, Darren Duncan dar...@darrenduncan.net wrote: 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. All RDBO tests pass, and it appears to have fixed this bug: http://rt.cpan.org/Public/Bug/Display.html?id=48393 -John ___ DBD-SQLite mailing list DBD-SQLite@lists.scsys.co.uk http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
[DBD-SQLite] Re: [sqlite] test DBD::SQLite 1.26_05 - foreign keys!
P Kishor wrote [on sqlite-us...@sqlite.org]: On Thu, Oct 15, 2009 at 1:39 AM, Darren Duncan dar...@darrenduncan.net wrote: 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). .. 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, I tried to create a db with FTS3 and got the following perl(12546) malloc: *** error for object 0x1eb160: Non-aligned pointer being freed (2) *** set a breakpoint in malloc_error_break to debug perl(12546) malloc: *** error for object 0x870200: double free *** set a breakpoint in malloc_error_break to debug perl(12546) malloc: *** error for object 0x1ea668: Non-aligned pointer being freed *** set a breakpoint in malloc_error_break to debug Segmentation fault Is the above the FTS3 related error? Looks similar. This is the official bug report that we already have, which was reported on Oct 14, and on which the failing/skipping test is based: http://rt.cpan.org/Public/Bug/Display.html?id=50503 Subject: Segfault with fts3 A copy of the ticket text is displayed below the dashed line in this email also. The bug report was against DBD::SQLite versions that bundled SQLite 3.6.13 and 3.6.18 respectively, for both of which the bug manifests. As of yet the bug is unfixed. If you have any new information, it would be useful for you to add it to the above RT ticket. -- Darren Duncan [text/plain 790b] The attached script fails on 1.25 and 1.26_04. It does one of three things: - segfaults - gives a double free error - hangs without any cpu activity Which of the above three it does depends on the exact script (adding or removing a print line can change its behavior), but it always fails. Here are a couple sample error messages: *** glibc detected *** double free or corruption (!prev): 0x0083c480 *** Abort (core dumped) Segmentation fault (core dumped) The database doesn't appear to be corrupted after the failure -- running an integrity check with the sqlite3 command line binary says the db is okay. The equivalent code without the fts3 module works fine. I did a quick test with the DBD::SQLite packaged with the latest Ubuntu (1.14), and that version seems to work. ___ DBD-SQLite mailing list DBD-SQLite@lists.scsys.co.uk http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
[DBD-SQLite] 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 ___ DBD-SQLite mailing list DBD-SQLite@lists.scsys.co.uk http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
Re: [DBD-SQLite] problems using sqlite with mod_perl in apache
Mike, off-hand it looks like you're trying to use SQLite 2.x and SQLite 3.x on
the same database. You can't do this as these 2 SQLite major versions are
incompatible with each other, with different file formats, and SQLite 3 won't
work with SQLite 2 files. Make sure you are using just DBD::SQLite2 (SQLite 2)
or DBD::SQLite (SQLite 3) with the same database on both the command-line and in
your web app. Note that the reason the DBD::SQLite which does SQLite v2 and v3
have different Perl package names is so that you can use both in the same
program at once, if you wanted to such as to do a conversion, though for
conversion using the SQLite command-line utility for dump and then load works
well, perhaps best, also. -- Darren Duncan
Mike Campbell wrote:
I've developed a small app that uses a webpage to insert/delete data
into a sqlite database. The script work find when I run them from the
command line but not when run from the webpage.
For example, using the following code:
$db = DBI-connect(dbi:SQLite2:dbname=/home/oracle/bugpush/bugpush.db,
, , { RaiseError = 1, AutoCommit = 1 }) || die( $DBI::errstr .
\n );
$sth = $db-prepare(select api_key, bugno, last_update_date, analyst
from tracked_bugs order by bugno);
if(! defined($sth) || ! ($sth)) {
print Failed to prepare SQL statement:\n;
print $DBI::errstr\n;
goto END;
}
In the apache error_log I see the following:
[Tue Dec 01 06:49:21 2009] [error] DBD::SQLite::db prepare failed: not
an error
at /home/oracle/bugpush/tracking.cgi
Oddly enough if I use the DBD::SQLite2 module this works just fine
(although the underlying db that is created is sqlite v2.x).
I have verified that this is not a permission problem as I have copied
the database file to /tmp/bugpush.db and set the permissions as 777 but
still get the same result.
Any ideas as to why this is failing to run with DBD-SQLite-1.27 but
works fine with DBD-SQLite2-0.33?
___
DBD-SQLite mailing list
DBD-SQLite@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
Re: [DBD-SQLite] problems using sqlite with mod_perl in apache
Mike Campbell wrote:
Ok here is what I get.
Test using DBD::SQLite (same output when used command-line and via webpage)
=
the SQLite v3 is 1.27
Test using DBD::SQLite2 (same output when used command-line and via webpage)
the SQLite v2 is 0.33
snip
At first glance you seem to be doing things adequately in your code samples.
However, your code looks very old-fashioned, maybe because you based it on old
code you saw somewhere, and making it into more modern Perl can probably help.
For starters, when you are using DBI, *always* configure it to throw exceptions
on errors rather than just return nothing.
Instead of this:
$db = DBI-connect(dbi:SQLite:dbname=/tmp/bugpush.db, , )
|| die( $DBI::errstr . \n );
... do this:
$db = DBI-connect(dbi:SQLite:dbname=/tmp/bugpush.db, , ,
{ RaiseError = 1 });
That alone should go further towards you getting useful error messages when you
should be.
Also you can remove all your tests like if(! defined($sth) || ! ($sth)) or if
(! defined( $rc ) ).
When DBI is set to throw exceptions, you can just code as if each step will work
and you don't need to test, since the program should die by itself if something
goes wrong.
Instead, you just do tests when you want the program to not die but rather be
more graceful when something goes wrong, and then you do it by setting up an
exception handler (an eval block), but we don't need to get into that now.
So try making those changes and see what effect is has.
I'm not immediately in the position to run your code myself, not having mod_perl
installed.
It would be helpful if you could provide more information on your setup.
What versions of Perl and DBI are you using, to start with.
To find out, you can use code like this:
my $perlvers = $[;
use DBI;
my $dbivers = $DBI::VERSION;
Run that on both command-line and mod-perl as usual.
Also your versions of Apache and mod_perl are useful to know.
Also try running your code under FastCGI, or CGI, rather than mod_perl and see
if that has any effect on the result. Include the tests for what
DBD::SQLite/etc version is running if necessary.
Maybe someone else on this list has ideas?
-- Darren Duncan
___
DBD-SQLite mailing list
DBD-SQLite@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
[DBD-SQLite] [Fwd: Re: [sqlite] SQLite bug ticket - build fails on sun4-solaris-64int 2.10]
Original Message Subject: Re: [sqlite] SQLite bug ticket - build fails on sun4-solaris-64int 2.10 Date: Sat, 02 Jan 2010 20:55:53 + From: Dr. David Kirkby david.kir...@onetel.net Reply-To: General Discussion of SQLite Database sqlite-us...@sqlite.org To: General Discussion of SQLite Database sqlite-us...@sqlite.org References: 4b3efa2a.3090...@darrenduncan.net Darren Duncan wrote: I would like to bring an apparent SQLite bug to the attention of the SQLite core developers as a ticket, where build fails on sun4-solaris-64int 2.10. This problem was reported to the DBD::SQLite (Perl binding) developers as an automatically generated smoke tester ticket which can be seen here for all the details, but I have copied the most central portion into this email below the dashed line: http://www.nntp.perl.org/group/perl.cpan.testers/2009/12/msg6529201.html Note that the DBD::SQLite version that was tested bundles SQLite 3.6.20, so there is a chance that the latest 3.6.21 fixes it; if you think it necessary I can try asking the tester to try with the newer version. Thank you. -- Darren Duncan I get the same warnings as Darren with Sun Studio - the Sun compiler tends to be more fussy than gcc. But my build does succeed. This is version 3.6.19 I assume. The output below is from a Sun Ultra 27 (Xeon processor), but I've built sqlite on Solaris 10 SPARC, from both the first version (02/2005) and the latest Solaris 10 update 7 (late 2009). /opt/sunstudio12.1/bin/cc -DPACKAGE_NAME=\sqlite\ -DPACKAGE_TARNAME=\sqlite\ -DPACKAGE_VERSION=\3.6.19\ -DPACKAGE_STRING=\sqlite 3.6.19\ -DPACKAGE_BUGREPORT=\http://www.sqlite.org\; -DPACKAGE=\sqlite\ -DVERSION=\3.6.19\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FDATASYNC=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1 -DHAVE_GMTIME_R=1 -DHAVE_READLINE=1 -I. -I. -I /export/home/drkirkby/sage-4.3/local/include -DSQLITE_THREADSAFE=1 -m64 -g -O2 -c sqlite3.c -KPIC -DPIC -o .libs/sqlite3.o sqlite3.c, line 19207: warning: integer overflow detected: op sqlite3.c, line 19224: warning: integer overflow detected: op sqlite3.c, line 33277: warning: statement not reached sqlite3.c, line 70955: warning: integer overflow detected: op /opt/sunstudio12.1/bin/cc -DPACKAGE_NAME=\sqlite\ -DPACKAGE_TARNAME=\sqlite\ -DPACKAGE_VERSION=\3.6.19\ -DPACKAGE_STRING=\sqlite 3.6.19\ -DPACKAGE_BUGREPORT=\http://www.sqlite.org\; -DPACKAGE=\sqlite\ -DVERSION=\3.6.19\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_FDATASYNC=1 -DHAVE_USLEEP=1 -DHAVE_LOCALTIME_R=1 -DHAVE_GMTIME_R=1 -DHAVE_READLINE=1 -I. -I. -I /export/home/drkirkby/sage-4.3/local/include -DSQLITE_THREADSAFE=1 -m64 -g -O2 -c sqlite3.c -o sqlite3.o /dev/null 21 I do not know how much access sqlite developers have to Solaris machines, but if they need access to a SPARC, I can get a serious developer access to a T5240 via the University of Washington. Just drop me an email, with your preferred user name and state your role in sqlite development. Dave ___ sqlite-users mailing list sqlite-us...@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ DBD-SQLite mailing list DBD-SQLite@lists.scsys.co.uk http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
[DBD-SQLite] [Fwd: Re: [sqlite] SQLite version 3.7.0]
Original Message Subject: Re: [sqlite] SQLite version 3.7.0 Date: Thu, 22 Jul 2010 18:31:42 +0700 From: Dan Kennedy danielk1...@gmail.com To: General Discussion of SQLite Database sqlite-us...@sqlite.org On Jul 22, 2010, at 1:08 PM, Darren Duncan wrote: snip On that note, I got this report from someone on Windows: Latest SVN trunk tested on win32 Strawberry perl v1.12.1 : all tests pass, no problem. ... and I was using a Unixen. Is there any way your tests could be deleting a database file while there is still an open sqlite connection to it? With 3.7.0, if the underlying database file is unlinked while you are connected to it, then you try to write to the database, you get SQLITE_IOERR_FSTAT. Earlier versions would continue writing without causing an error. You cannot delete a file while it is open on windows, so this doesn't come up on win32. This happened with a couple of Tcl tests too. ___ DBD-SQLite mailing list DBD-SQLite@lists.scsys.co.uk http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
Re: [DBD-SQLite] SQLite 3.7.x problem fixed, please dev-release
Kenichi Ishigaki wrote: Hi. Sorry that I had little time recently and didn't fix the issue on sqlite numbers for 64 bit environments. I tentatively disabled it as it is rather a big change and might break other distributions' tests that expected every bind param was a quoted text for sqlite. I'll look into it again after we ship the next non-dev release. Best, Kenichi Thank you for the timeliness of these corrections, which got in prior to Adam making the developer release. Under the circumstances, I recommend releasing what we have now as version 1.31 production within a week if there are no showstopper problems discovered with 1.30_04 in the meantime. In preparation for that, I'll send out a few emails now asking for people to test 1.30_04, which has some large changes from 1.29. -- Darren Duncan ___ DBD-SQLite mailing list DBD-SQLite@lists.scsys.co.uk http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
Re: [DBD-SQLite] policy for FTS5 integration ?
I believe the best option is d) to support both FTS4 and FTS5 at the same time, as if they were different data types. Failing that, I like b) the best. I also think a) is the worst option; this is not something worth forking over. -- Darren Duncan On 2015-10-25 11:46 PM, Dami Laurent (PJ) wrote: Hi there, I noticed that the 3.9.0 amalgamation now contains FTS5. So it’s time to think about the evolution of FTS support in DBD::Sqlite. At the moment, FTS5 is still experimental, but at some point it will stabilize and become mainstream. FTS5 contains incompatible changes from FTS3/4 (see http://www.sqlite.org/fts5.html#appendix_a). Some of those incompatibilities can be handled in the DBD::Sqlite driver and therefore will be invisible to users ; but some other points change the SQL API to FTS and therefore **will** be visible. So what should be the future evolution of DBD::Sqlite with respect to FTS ? Here are some options : a)Stick with FTS4 forever to preserve backwards compatibility, and fork a new distrib DBD::SQLite::FTS5 (but then how to keep both distribs in sync ?) b)Target for a backwards-incompatible move to FTS5 at some point in the future, and advertise it long in advance c)Support 2 variants, with an option in Makefile.PL to choose the FTS version at compilation time (but this could be a nightmare for automatic toolchains). d)Try to simultaneously activate FTS3 and FTS5 in the same compilation (I don’t know if this is possible), and let users choose through runtime options. e)Any other idea ? DBD::Sqlite never encountered this issue before, because the first FTS support was for FTS3, and then when sqlite.org introduced FTS4 it was fully compatible with FTS3. The only somewhat similar situation was in2010 when the FTS syntax changed from « Standard Query Syntax » to « Extended Query Syntax » ; at that time I published the DBD::Sqlite::FTS3Transitional module to help with the migration, but this time it will not be that simple. So what do you think ? My personal preference would be for option b). It’s not very nice to break backwards compatibility, but sometimes it must happen. Besides, I never saw any public discussions, comments or bug reports about FTS support in DBD ::Sqlite, so the user community is probably quite small, and therefore the impact of such a change would be limited. Of course this should only be activated when FTS5 has becomes stable, which should still take a couple of months. Once the policy issue is settled, I’m interested to volunteer for working on the technical aspects – but I have very little free time to do so, so I will not progress very fast. If anybody else has more time, they are welcome to take the job. Cheers, Laurent Dami ___ DBD-SQLite mailing list DBD-SQLite@lists.scsys.co.uk http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
