FAQ
Update ...

Thanks to Niko Tyni (Debian Perl Group), a patch to fix the incompatibility with
SQLite 3.7.x has been handed to us via RT (
https://rt.cpan.org/Public/Bug/Display.html?id`698 ). It was just 3 lines for
test.pm.

The patch was written against 1.29 but I tested it against both 1.30_03 and
trunk and it fixed the test failures under 3.7.x for both.

Since my earlier report of this problem, 3 more SQLite releases came out, and
I've added all 3 to DBD::SQLite at the time; 3.7.2 is now the latest; upgrading
to it is officially recommended for users of all prior releases.

I also un-TODO'd 3 other tests which now pass, but didn't in 1.30_03.

I also skipped-all t_44891_strings_look_like_numbers.t which has a few
still-failing tests (some large integers are formatted in scientific notation
like floats) so that we can ship the 3.7.x fix ASAP.

That test had been added after 1.30_03 came out, and fails with that release too.

Adam, can you please cut 1.30_04 now? (Don't forget to update the release date
in the Changes file.)

The test suite all passes now, for me.

The t_44891_strings_look_like_numbers.t will still need dealing with somehow
prior to a non-dev release, I suppose.

Thank you. -- Darren Duncan

Search Discussions

  • Adam Kennedy at Aug 25, 2010 at 1:19 am
    Will do
    On 25 Aug 2010 09:53, "Darren Duncan" wrote:
    Update ...

    Thanks to Niko Tyni (Debian Perl Group), a patch to fix the
    incompatibility with
    SQLite 3.7.x has been handed to us via RT (
    https://rt.cpan.org/Public/Bug/Display.html?id=60698 ). It was just 3 lines for
    test.pm.

    The patch was written against 1.29 but I tested it against both 1.30_03 and
    trunk and it fixed the test failures under 3.7.x for both.

    Since my earlier report of this problem, 3 more SQLite releases came out, and
    I've added all 3 to DBD::SQLite at the time; 3.7.2 is now the latest; upgrading
    to it is officially recommended for users of all prior releases.

    I also un-TODO'd 3 other tests which now pass, but didn't in 1.30_03.

    I also skipped-all t_44891_strings_look_like_numbers.t which has a few
    still-failing tests (some large integers are formatted in scientific notation
    like floats) so that we can ship the 3.7.x fix ASAP.

    That test had been added after 1.30_03 came out, and fails with that
    release too.
    Adam, can you please cut 1.30_04 now? (Don't forget to update the release date
    in the Changes file.)

    The test suite all passes now, for me.

    The t_44891_strings_look_like_numbers.t will still need dealing with somehow
    prior to a non-dev release, I suppose.

    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
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/dbd-sqlite/attachments/20100825/adabc2e0/attachment.htm
  • Kenichi Ishigaki at Aug 25, 2010 at 3:27 am
    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
    On Wed, 25 Aug 2010 11:19:59 +1000, Adam Kennedy wrote:

    Will do
    On 25 Aug 2010 09:53, "Darren Duncan" wrote:
    Update ...

    Thanks to Niko Tyni (Debian Perl Group), a patch to fix the
    incompatibility with
    SQLite 3.7.x has been handed to us via RT (
    https://rt.cpan.org/Public/Bug/Display.html?id`698 ). It was just 3 lines for
    test.pm.

    The patch was written against 1.29 but I tested it against both 1.30_03 and
    trunk and it fixed the test failures under 3.7.x for both.

    Since my earlier report of this problem, 3 more SQLite releases came out, and
    I've added all 3 to DBD::SQLite at the time; 3.7.2 is now the latest; upgrading
    to it is officially recommended for users of all prior releases.

    I also un-TODO'd 3 other tests which now pass, but didn't in 1.30_03.

    I also skipped-all t_44891_strings_look_like_numbers.t which has a few
    still-failing tests (some large integers are formatted in scientific notation
    like floats) so that we can ship the 3.7.x fix ASAP.

    That test had been added after 1.30_03 came out, and fails with that
    release too.
    Adam, can you please cut 1.30_04 now? (Don't forget to update the release date
    in the Changes file.)

    The test suite all passes now, for me.

    The t_44891_strings_look_like_numbers.t will still need dealing with somehow
    prior to a non-dev release, I suppose.

    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
    _______________________________________________
    DBD-SQLite mailing list
    DBD-SQLite@lists.scsys.co.uk
    http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite
  • Darren Duncan at Aug 25, 2010 at 7:38 pm

    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
  • Toby Corkindale at Aug 26, 2010 at 2:08 am

    On 26/08/10 05:38, Darren Duncan wrote:
    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.
    It sounds like there are some quite major changes in this version of
    SQLite, and thus also DBD::SQLite.

    As with other major releases, I'm interested in testing the dev release
    against our code which does tend to stress SQLite - however this isn't
    something I can fit in in the time frame you're discussing ("within a
    week").

    I am sure I'm not the only person in this situation.

    Do you really need to release a so-called "stable" version so rapidly?
    If what you have now is a release candidate, then would you mind leaving
    it for a bit longer while people have a chance to shake it out?

    DBD::SQLite is a major piece of many applications. Please be careful
    what you nominate as "stable".

    Thanks for your efforts in keeping it up to date and incorporating
    upstream improvements - it's really appreciated.

    -Toby
  • Darren Duncan at Aug 26, 2010 at 2:35 am

    Toby Corkindale wrote:
    On 26/08/10 05:38, Darren Duncan wrote:
    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.
    It sounds like there are some quite major changes in this version of
    SQLite, and thus also DBD::SQLite.

    As with other major releases, I'm interested in testing the dev release
    against our code which does tend to stress SQLite - however this isn't
    something I can fit in in the time frame you're discussing ("within a
    week").

    I am sure I'm not the only person in this situation.

    Do you really need to release a so-called "stable" version so rapidly?
    If what you have now is a release candidate, then would you mind leaving
    it for a bit longer while people have a chance to shake it out?

    DBD::SQLite is a major piece of many applications. Please be careful
    what you nominate as "stable".

    Thanks for your efforts in keeping it up to date and incorporating
    upstream improvements - it's really appreciated.
    Keep in mind, first of all, that most bugs of any consequence would be in SQLite
    itself. SQLite itself has already had 3 patch releases since 3.7.0 which
    introduced the major changes, and 3.7.0 came out a full month ago. Meanwhile
    3.7.0.1 came which fixed a few bugs, then 3.7.1 with a greater number of
    changes, and then 3.7.2 which just fixed a bug. So the codebase with the most
    serious likelihood of issues has already had a month of shake-out, and moreover
    the SQLite itself has 100% test coverage.

    Granted, DBD::SQLite has relatively little test coverage, and mostly piggybacks
    on assuming SQLite itself or Perl itself is fine.

    That all being said, how much time do you need to do your stress test? Two weeks?

    -- Darren Duncan
  • Toby Corkindale at Aug 26, 2010 at 3:02 am

    On 26/08/10 12:35, Darren Duncan wrote:
    Toby Corkindale wrote:
    On 26/08/10 05:38, Darren Duncan wrote:
    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.
    It sounds like there are some quite major changes in this version of
    SQLite, and thus also DBD::SQLite.

    As with other major releases, I'm interested in testing the dev
    release against our code which does tend to stress SQLite - however
    this isn't something I can fit in in the time frame you're discussing
    ("within a week").

    I am sure I'm not the only person in this situation.

    Do you really need to release a so-called "stable" version so rapidly?
    If what you have now is a release candidate, then would you mind
    leaving it for a bit longer while people have a chance to shake it out?

    DBD::SQLite is a major piece of many applications. Please be careful
    what you nominate as "stable".

    Thanks for your efforts in keeping it up to date and incorporating
    upstream improvements - it's really appreciated.
    Keep in mind, first of all, that most bugs of any consequence would be
    in SQLite itself. SQLite itself has already had 3 patch releases since
    3.7.0 which introduced the major changes, and 3.7.0 came out a full
    month ago. Meanwhile 3.7.0.1 came which fixed a few bugs, then 3.7.1
    with a greater number of changes, and then 3.7.2 which just fixed a bug.
    So the codebase with the most serious likelihood of issues has already
    had a month of shake-out, and moreover the SQLite itself has 100% test
    coverage.
    I understand that most of the issues would be in SQLite rather than
    DBD::SQLite, but the Perl world hasn't tested that either yet.

    I appreciate that both have unit test coverage, but just testing each
    line of code doesn't guarantee you find odd edge cases in real-world
    situations, nor odd interactions on particular operating systems, perl
    or compiler versions.
    Granted, DBD::SQLite has relatively little test coverage, and mostly
    piggybacks on assuming SQLite itself or Perl itself is fine.

    That all being said, how much time do you need to do your stress test?
    Two weeks?
    I and my colleagues should be able to get some testing done in the next
    fortnight, sure.

    I suspect many people will only catch the announcement via your posts on
    other DB-related lists, so may take a while to get around to testing as
    well.

    Things will probably be OK in the end, but I do want to suggest that
    there isn't a huge rush to get a "stable" version released to CPAN, so
    maybe when there are "major" released like this, you could give people
    weeks rather than days to test them in?

    Thanks for your understanding,
    Toby
  • Darren Duncan at Aug 26, 2010 at 4:40 am

    Toby Corkindale wrote:
    That all being said, how much time do you need to do your stress test?
    Two weeks?
    I and my colleagues should be able to get some testing done in the next
    fortnight, sure.

    I suspect many people will only catch the announcement via your posts on
    other DB-related lists, so may take a while to get around to testing as
    well.

    Things will probably be OK in the end, but I do want to suggest that
    there isn't a huge rush to get a "stable" version released to CPAN, so
    maybe when there are "major" released like this, you could give people
    weeks rather than days to test them in?

    Thanks for your understanding,
    Toby
    In any event, Adam is the one that actually does releases. I make suggestions
    about releases, and any comment I made about in-a-week should just be read as
    "might happen that way" rather than a promise. Given your input, I suggest that
    Adam waits 2 weeks and then releases 1.31, barring any show-stoppers being
    reported. -- Darren Duncan
  • Adam Kennedy at Aug 27, 2010 at 7:51 am
    Quite a few FAIL reports, mostly around Test::NoWarnings in fts3.t

    I'm on flaky connection, but if someone can fix it I'll drop another
    dev release tonight.

    Adam K
    On Thu, Aug 26, 2010 at 5:38 AM, Darren Duncan wrote:
    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
  • Kenichi Ishigaki at Aug 27, 2010 at 1:40 pm
    Fixed the Test::NoWarnings issue (hopefully). Bumped up the
    version, and updated Changes. Please ship the next dev one.
    Thanks,

    Kenichi

    On Fri, 27 Aug 2010 17:51:56 +1000, Adam Kennedy wrote:

    Quite a few FAIL reports, mostly around Test::NoWarnings in fts3.t

    I'm on flaky connection, but if someone can fix it I'll drop another
    dev release tonight.

    Adam K
    On Thu, Aug 26, 2010 at 5:38 AM, Darren Duncan wrote:
    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
  • Adam Kennedy at Aug 25, 2010 at 9:25 am
    Released as http://svn.ali.as/cpan/releases/DBD-SQLite-1.30_04.tar.gz
    On 25 August 2010 11:19, Adam Kennedy wrote:
    Will do
    On 25 Aug 2010 09:53, "Darren Duncan" wrote:
    Update ...

    Thanks to Niko Tyni (Debian Perl Group), a patch to fix the
    incompatibility with
    SQLite 3.7.x has been handed to us via RT (
    https://rt.cpan.org/Public/Bug/Display.html?id`698 ). It was just 3
    lines for
    test.pm.

    The patch was written against 1.29 but I tested it against both 1.30_03
    and
    trunk and it fixed the test failures under 3.7.x for both.

    Since my earlier report of this problem, 3 more SQLite releases came out,
    and
    I've added all 3 to DBD::SQLite at the time; 3.7.2 is now the latest;
    upgrading
    to it is officially recommended for users of all prior releases.

    I also un-TODO'd 3 other tests which now pass, but didn't in 1.30_03.

    I also skipped-all t_44891_strings_look_like_numbers.t which has a few
    still-failing tests (some large integers are formatted in scientific
    notation
    like floats) so that we can ship the 3.7.x fix ASAP.

    That test had been added after 1.30_03 came out, and fails with that
    release too.

    Adam, can you please cut 1.30_04 now? (Don't forget to update the release
    date
    in the Changes file.)

    The test suite all passes now, for me.

    The t_44891_strings_look_like_numbers.t will still need dealing with
    somehow
    prior to a non-dev release, I suppose.

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbd-sqlite @
postedAug 24, '10 at 11:53p
activeAug 27, '10 at 1:40p
posts11
users5
websiteshadowcat.co.uk

People

Translate

site design / logo © 2021 Grokbase