Bug #63455 for HTML-FormHandler-Model-DBIC: t/book.t or t/process.t fails unit tests due to "Duplicate ISBN"

Mon Nov 29 20:47:40 2010 TJC [...] cpan.org - Ticket created

CC:	toby.corkindale [...] strategicdata.com.au
Subject:	t/book.t or t/process.t fails unit tests due to "Duplicate ISBN"

I'm getting failures on the HFH-Model-DBIC unit test suite. Depending on the number of times I've run the tests, either book.t or process.t fails on the "Good data" test. Digging deeper, the error is due to a duplicate ISBN value. Reported as: <div class="error"><label class="label" for="isbn">ISBN: </label><input type="text" name="isbn" id="isbn" value="123-02345-0502-2" /> <span class="error_message">Duplicate value for ISBN</span></div> If I re-create the database, or re-extract it, then things pass; however it seems poor form for the test to be so delicate as to be one-time- only. Maybe I suggest that the test suite automatically (re)create the database every time from the bookdb.sql file? I see there is an END block which is meant to delete the inserted book at the end of each test, but it appears this mechanism is failing. I'm testing on Perl 5.12.2 (threaded) with current-as-of-today CPAN modules, ie. DBI=1.615 DBD::SQLite=1.31 Test::More=0.96 DBIx::Class=0.08124

Mon Nov 29 21:06:12 2010 TJC [...] cpan.org - Correspondence added

I have discovered the reason the END block isn't working (and thus leaving the data lying around for the next test to trip over). When the END block is called, $book->delete causes a segfault in Class::XSAccessor Oh dear :(

Mon Nov 29 21:06:13 2010 TJC [...] cpan.org - Status changed from 'new' to 'open'

Mon Nov 29 21:20:36 2010 TJC [...] cpan.org - Dependency on ticket #63458 added

Wed Dec 01 22:56:12 2010 TJC [...] cpan.org - Correspondence added

On Mon Nov 29 21:06:12 2010, TJC wrote: Show quoted text

> I have discovered the reason the END block isn't working (and thus > leaving the data lying around for the next test to trip over). > > When the END block is called, $book->delete causes a segfault in > Class::XSAccessor > > Oh dear :(

Class::XSAccessor 1.10 fixes this issue.

Thu Dec 02 15:51:59 2010 gshank [...] cpan.org - Correspondence added

On Wed Dec 01 22:56:12 2010, TJC wrote: Show quoted text

> On Mon Nov 29 21:06:12 2010, TJC wrote:

> > I have discovered the reason the END block isn't working (and thus > > leaving the data lying around for the next test to trip over). > > > > When the END block is called, $book->delete causes a segfault in > > Class::XSAccessor > > > > Oh dear :(

> > Class::XSAccessor 1.10 fixes this issue.

FormHandler doesn't prereq Class::XSAccessor itself. Is there an intermediate prereq? Trying to figure out if I should bump a prereq...

Thu Dec 02 18:42:37 2010 TJC [...] cpan.org - Correspondence added

On Thu Dec 02 15:51:59 2010, GSHANK wrote: Show quoted text

> On Wed Dec 01 22:56:12 2010, TJC wrote:

> > On Mon Nov 29 21:06:12 2010, TJC wrote:

> > > I have discovered the reason the END block isn't working (and thus > > > leaving the data lying around for the next test to trip over). > > > > > > When the END block is called, $book->delete causes a segfault in > > > Class::XSAccessor > > > > > > Oh dear :(

> > > > Class::XSAccessor 1.10 fixes this issue.

> > FormHandler doesn't prereq Class::XSAccessor itself. Is there an > intermediate prereq? Trying to figure out if I should bump a prereq...

You depend on DBIx::Class, which depends on Class::Accessor::Grouped, which depends on Class::XSAccessor. C:A:G is going to bump their prereq version up though. The related tickets are: https://rt.cpan.org/Public/Bug/Display.html?id=63459 https://rt.cpan.org/Public/Bug/Display.html?id=63458 Cheers, Toby

Mon Sep 19 13:06:46 2011 gshank [...] cpan.org - Correspondence added

Fixed in dependency a while back...

Mon Sep 19 13:06:47 2011 gshank [...] cpan.org - Status changed from 'open' to 'resolved'