Quantcast

mysql timestamp problem causing test failure when using sort.

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

mysql timestamp problem causing test failure when using sort.

John P. Rouillard
Hi All:

Yesterday I committed some code that filters the journal/history and
removes entries that refer to properties that the user can't view
(issue2550864).

I wrote tests and tested on my system with the three db's I use:
sqlite, memory and anydb. Everything looked good so I checked it in.
I also moved the new code to John K's (jerrykan) git/CI
infrastructure.

I was surprised to find that mysql tests were failing.

My test code does:

    result=self.db.issue.history(new_issue)
    result.sort()
    (id, tx_date, user, action, args) = result[-1]
    ...

The test fails in:

    self.assertEqual(expected, args)    

I was expecting:

    expected = {'nosy': (('+', ['1']), ('-', ['3'])),
                'deadline': date.Date("2016-07-30.22:39:00.000")}

but the test got a different value for args:

    'title': 'title', 'deadline': <Date 2016-06-30.22:39:00.000>,
    'nosy': (('+', [' [truncated]...

the full sorted result is:

   [('1', <Date 2017-04-15.04:06:58.000>, '1', 'create', {}),
    ('1', <Date 2017-04-15.04:06:59.000>, '1', 'set',
        {'nosy': (('+', ['1']), ('-', ['3'])),
         'deadline': <Date 2016-07-30.22:39:00.000>}),
    ('1', <Date 2017-04-15.04:06:59.000>, '1', 'set',
        {'title': 'title', 'deadline': <Date 2016-06-30.22:39:00.000>,
         'nosy': (('+', ['3', '2']),)})]

Note that the two datestamps (the second field in the tuples) is
identical for the last two entries. I assume this results in the sort
order being determined by something other than timestamp of the set
actions.

My test fails because I am expecting the second from last entry to be
the last entry.

>From reading https://dev.mysql.com/doc/refman/5.7/en/datetime.html it
looks like mysql supports fractional (micro) seconds and support is
given for truncating the number of seconds in 5.7 and newer, but the
default should be microsecond default.

But that does not appear to be used as every timestamp in the result
has 0 fractional seconds.

So I am looking for ideas on how to handle this.

The code I checked in is at:

  https://sourceforge.net/p/roundup/code/ci/462b0f76fce88430badbd4a8de047b49a854a638/

(This isn't the tip of the default branch. The tip has an extra print
 statement for debugging the test.)

It looks like I need to find a different way to select the
history/journal entry than sorting and choosing the last one.  However
I still want my tests to succeed if the timestamp issue is corrected,
or if the sort order turns out to not be deterministic and flips.

I have considered:

  check the dictionary in the last or second from the last journal
  tuples. Whichever one matches is used for the assert tests.

  sleep for 2-3 seconds between the first and second set actions.
  That way I will have timestamps that are a second apart at least.
  But this seems wasteful and wrong.

The proper thing to do is to figure out why the fractional seconds are
lost in mysql and see if that can be fixed (may require a minimum
mysql version requirement). But that's way beyond my comfort zone.

Does anybody have suggestions/ideas on how to handle this issue?

--
                                -- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Roundup-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/roundup-devel
Loading...