testInsertGetWithoutTimestamp testcase fails

Bug #486996 reported by Markus Korn
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Zeitgeist Framework
Fix Released
Undecided
Unassigned

Bug Description

Running
   python test/resonance-engine-test.py
I get one failed testcase

======================================================================
FAIL: testInsertGetWithoutTimestamp (__main__.ZeitgeistEngineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test/resonance-engine-test.py", line 87, in testInsertGetWithoutTimestamp
    self.assertTrue(ev.timestamp)
AssertionError

----------------------------------------------------------------------

I would have fixed this if I were totally sure what the correct fix is. Right now the default timestamp of an event is an empty string, which is why this testcase fails. Is this the expected behaviour, and should we fix the test. Or should the default timestamp be a string containing the timestamp of object creation time?

Markus Korn (thekorn)
Changed in zeitgeist:
milestone: none → 0.3
Revision history for this message
Mikkel Kamstrup Erlandsen (kamstrup) wrote :

I think a nice default is to use the timestamp of object creation time. That was the idea behind the test at least, and indeed it also worked like that at some point (where the test worked). Otoh - the engine will use the current time as timestamp if the incoming event doesn't have one, so it might be nicer to leave it out...

That said - Having the engine assign timestamps does give a slight lag on the stamps though, so that's why I prefer having the client generated.

And just so that we are sure we agree; timestamps are millis since epoch, ie. int(time.time()*1000). In the Event case it needs to be a string, so wrap a str() around that.

Markus Korn (thekorn)
Changed in zeitgeist:
status: New → Triaged
Revision history for this message
Seif Lotfy (seif) wrote :

We should not even allow empty timestamps in. But if you guys think we should then an empty timestamp means we should generate one using time.time() and insert it into the DB. What do u think?

Revision history for this message
Mikkel Kamstrup Erlandsen (kamstrup) wrote :

@Seif: I think we can allow empty timestamps for convenience. And as I said in comment 1 paragraph 3; we meassure time in milliseconds, hence timestamps are genrated with int(time.time()*1000).

Revision history for this message
Seif Lotfy (seif) wrote : Re: [Bug 486996] Re: testInsertGetWithoutTimestamp testcase fails

which convenience

2009/11/23 Mikkel Kamstrup Erlandsen <email address hidden>

> @Seif: I think we can allow empty timestamps for convenience. And as I
> said in comment 1 paragraph 3; we meassure time in milliseconds, hence
> timestamps are genrated with int(time.time()*1000).
>
> --
> testInsertGetWithoutTimestamp testcase fails
> https://bugs.launchpad.net/bugs/486996
> You received this bug notification because you are subscribed to The
> Zeitgeist Project.
>
> Status in Zeitgeist Engine: Triaged
>
> Bug description:
> Running
> python test/resonance-engine-test.py
> I get one failed testcase
>
> ======================================================================
> FAIL: testInsertGetWithoutTimestamp (__main__.ZeitgeistEngineTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "test/resonance-engine-test.py", line 87, in
> testInsertGetWithoutTimestamp
> self.assertTrue(ev.timestamp)
> AssertionError
>
> ----------------------------------------------------------------------
>
> I would have fixed this if I were totally sure what the correct fix is.
> Right now the default timestamp of an event is an empty string, which is why
> this testcase fails. Is this the expected behaviour, and should we fix the
> test. Or should the default timestamp be a string containing the timestamp
> of object creation time?
>
>

Revision history for this message
Mikkel Kamstrup Erlandsen (kamstrup) wrote :

@Seif: I wouldn't have to care about the timestamp format when sending events if my app doesn't need high precision timing. Just create the Event instance and send it along. Recall that not all apps will be written in Python and using our client libs...

Revision history for this message
Seif Lotfy (seif) wrote :

@Mikkel: OK I get ur point :)

2009/11/23 Mikkel Kamstrup Erlandsen <email address hidden>

> @Seif: I wouldn't have to care about the timestamp format when sending
> events if my app doesn't need high precision timing. Just create the
> Event instance and send it along. Recall that not all apps will be
> written in Python and using our client libs...
>
> --
> testInsertGetWithoutTimestamp testcase fails
> https://bugs.launchpad.net/bugs/486996
> You received this bug notification because you are subscribed to The
> Zeitgeist Project.
>
> Status in Zeitgeist Engine: Triaged
>
> Bug description:
> Running
> python test/resonance-engine-test.py
> I get one failed testcase
>
> ======================================================================
> FAIL: testInsertGetWithoutTimestamp (__main__.ZeitgeistEngineTest)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "test/resonance-engine-test.py", line 87, in
> testInsertGetWithoutTimestamp
> self.assertTrue(ev.timestamp)
> AssertionError
>
> ----------------------------------------------------------------------
>
> I would have fixed this if I were totally sure what the correct fix is.
> Right now the default timestamp of an event is an empty string, which is why
> this testcase fails. Is this the expected behaviour, and should we fix the
> test. Or should the default timestamp be a string containing the timestamp
> of object creation time?
>
>

Revision history for this message
Mikkel Kamstrup Erlandsen (kamstrup) wrote :

Fixed in r1158

Changed in zeitgeist:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.