Roundup Tracker - Issues

Issue 679217

classification
missing last transaction calling db.history from reactor
Type: Severity: normal
Components: Database Versions:
process
Status: closed fixed
:
: richard : richard
Priority: normal :

Created on 2003-02-02 21:40 by anonymous, last changed 2003-02-07 01:00 by anonymous.

Messages
msg620 Author: [hidden] (anonymous) Date: 2003-02-02 21:40
Roundup 0.5.5, cygwin python.

In a reactor, I am 
attempting to discover who changed
the assignedto attribute 
(that caused my reactor
to fire) by looking at the change history 
of the issue.

I can get a list of the history inside my reactor, 
but the
last change is missing from the list.

The ideas 
that come to mind are:

  a missing commit to disk for the 
database between
       the auditor and reactor triggers

  
db.history/db.getjournal functions do not use the
       cached 
database

I have taken a brief look through the 
back_anydbm.py
file and I think these are both the problem, 
but I am not sure how to solve it.

It looks like the call 
sequence is

  fire auditors
  call db.addjournal
     which 
calls doSaveJournal
      which calls getCacheJournalDB
  fire 
reactors

in the reactor code I call:

  
history.getAttributeHistory (my library)
      db.history  (wrong 
docs btw. return 5 tuple not 4)
          db.getjournal
              
db.opendb(filename)
         
I think the problem is that the change 
to the assignedto
field is still in the cached database (since it 
shows up in the web page), but getjournal is not using the 
cache
and therefore missing the data I need.

-- rouilj
msg621 Author: [hidden] (richard) Date: 2003-02-06 02:51
Logged In: YES 
user_id=6405

The required information is available through other means, so I'm closing 
this issue. 
 
msg622 Author: [hidden] (anonymous) Date: 2003-02-07 01:00
Logged In: NO 

Richard:

I agree with the fact that the information for this specific 
problem is available in another way.

I don't agree that it shouldn't 
be fixed. It just seems broken
that the reactor gets an incorrect view of 
the journal. By the
time the reactor sees the journal, the transaction it 
is
responding to has been commited, but its not in the 
journal
received by the reactor.

Say I have a function that 
analyzed the data from the journal
looking for more than three entries 
into a testing state. If I
call it from an external script immediatly after 
making the
fourth test state entry, everything works fine. If I call 
the
same function from a reactor, it fails if the trigger caused 
a
transition to the fourth testing state since its not present in
the 
journal.

I would have to fake additional journal entries in my 
reactor
code to make the function work. This is really ugly.

-- 
rouilj
msg623 Author: [hidden] (richard) Date: 2003-02-07 01:05
Logged In: YES 
user_id=6405

OK, OK :) 
 
Gah, I _really_ have to replace this awful tracker with Roundup ;) 
 
History
Date User Action Args
2003-02-02 21:40:06anonymouscreate