Bug #48385 for DBIx-Class-TimeStamp: Failing tests t/06timestamp.t and t/07date.t

Mon Aug 03 03:52:10 2009 kmx [...] cpan.org - Ticket created

Subject:

Failing tests t/06timestamp.t and t/07date.t

Hi, I have experienced the following failures during test while trying to install DBIx-Class-TimeStamp-0.12 t/05datetime.t ..... ok # Failed test 'update and create timestamp' # at t/06timestamp.t line 28. # got: '2009-08-02T22:45:56' # expected: '2009-08-02T22:45:55' # Looks like you failed 1 test of 3. t/06timestamp.t .... # Failed test 'update and create timestamp' # at t/07date.t line 28. # got: '2009-08-02T22:45:58' # expected: '2009-08-02T22:45:57' # Looks like you failed 1 test of 3. My perl - win32 strawbarry perl 5.8.9; however it does not seem to be a win32 specific issue. As you can see it is a sort of timing problem and does not happen always. I think that with current implementation you cannot assume update and create timestamps to be exactly the same. Changing tests in the following way could solve this issue: -is $row->t_updated, $row->t_created, 'update and create timestamp'; +cmp_ok($row->t_updated, '>=', $row->t_created, 'update and create timestamp'); -- kmx

Mon Aug 03 03:53:58 2009 kmx [...] cpan.org - Status changed from 'new' to 'open'

Fri Aug 14 09:48:38 2009 kmx [...] cpan.org - Correspondence added

Hi, can I somehow help with getting a fix for the issue discussed in this RT into official release? If you give me a feedback whether you prefer to patch the test (not testing createtime==updatetime but createtime<=updatetime) or to patch the module to assure the createtime to be exactly the same value as updatetime - I can try to prepare a patch. -- kmx

Mon Aug 17 09:33:35 2009 jjnapiork [...] cpan.org - Correspondence added

On Fri Aug 14 09:48:38 2009, KMX wrote: Show quoted text

> Hi, > > can I somehow help with getting a fix for the issue discussed in this RT > into official release? > > If you give me a feedback whether you prefer to patch the test (not > testing createtime==updatetime but createtime<=updatetime) or to patch > the module to assure the createtime to be exactly the same value as > updatetime - I can try to prepare a patch. > > -- > kmx

Honestly the only thing I can think of is to either 1) rewrite the tests so that all these bits don't need to be equal or 2) skip the tests in cases where the fine grained time module is not present. 1 Is probably the only way we are going to fix it for certain. john

Mon Aug 17 09:52:52 2009 rafl [...] debian.org - Correspondence added

Subject:	Re: [rt.cpan.org #48385] Failing tests t/06timestamp.t and t/07date.t
Date:	Mon, 17 Aug 2009 15:52:24 +0200
To:	John Napiorkowski via RT <bug-DBIx-Class-TimeStamp [...] rt.cpan.org>
From:	Florian Ragwitz <rafl [...] debian.org>

On Mon, Aug 17, 2009 at 09:33:35AM -0400, John Napiorkowski via RT wrote: Show quoted text

> Honestly the only thing I can think of is to either 1) rewrite the tests > so that all these bits don't need to be equal or 2) skip the tests in > cases where the fine grained time module is not present. > > 1 Is probably the only way we are going to fix it for certain.

Actually, extending DBIx::Class::DynamicDefault to give it some functionality to invoke a callback only once for a set of columns. Using that would get rid of the race condition that makes these tests fail. I'd suggest something like dynamic_default_on_update => \'some_other_column' to declare combined or dependant or whatever dynamic defaults. -- BOFH excuse #365: parallel processors running perpendicular today

Download signature.asc
application/pgp-signature 189b

Message body not shown because it is not plain text.

Wed Aug 26 12:33:38 2009 kmx [...] cpan.org - Correspondence added

Show quoted text

> Actually, extending DBIx::Class::DynamicDefault to give it some > functionality to invoke a callback only once for a set of columns. > > Using that would get rid of the race condition that makes these tests > fail. > > I'd suggest something like > > dynamic_default_on_update => \'some_other_column' > > to declare combined or dependant or whatever dynamic defaults.

Sounds reasonable but at the moment we cannot guarantee the created/updated timestamps to be equal (and it is a question whether we need to) therefore we probably should not test it. So, I vote for skipping the test for now. -- kmx

Fri May 21 20:29:15 2010 ddascalescu+perl [...] gmail.com - Correspondence added

I also get this one-second difference in t/06timestamp.t

Show quoted text

#   Failed test 'update and create timestamp'
#   at t/06timestamp.t line 28.
#          got: '2010-05-22T00:18:55'
#     expected: '2010-05-22T00:18:54'
# Looks like you failed 1 test of 3.

Strawberry Perl 5.10.1.

Maybe just implement a one-second tolerance in the test?