Associated Data - wf_exec_id behavior
Derik and I are running into a rather odd problem when querying the ASSOCIATED_DATA table for records. It appears that the WF_EXEC_ID column is behaving as a varchar column even though everything says it is an integer. After running a workflow (with WRP suite) I see 3 rows in the table for execution id 0, but only if I look for them with the like '%0%' syntax:
SELECT data.md5, ad.* FROM ASSOCIATED_DATA ad, DATA data WHERE data.md5 = ad.data_id and ad.wf_exec_id like '%0%'
using a numeric operator (=) does not return records (even though the table "looks" like it should yield them:
SELECT data.md5, ad.* FROM ASSOCIATED_DATA ad, DATA data WHERE data.md5 = ad.data_id and ad.wf_exec_id = 0
My DB browser shows the column as an INTEGER. And the prepared statements all use setInt() methods when interacting with the table...at my wits' end!
#3 Updated by Derik Barseghian over 11 years ago
This is what I did, twice, to the same effect, but if it's a race condition I wouldn't be surprised if it was just coincidence that I got errors on the third kepler instance both times.
1) Using wrp suite, run a wf two times.
2) Right click on the runs, Export. This works. Do the export again. Works again.
3) Close and reopen kepler. Repeat 2). Works again.
4) Repeat 3). This third try is when I got the below:
ERROR (org.kepler.kar.handlers.ReportInstanceKAREntryHandler:saveReportInstanceForWorkflowRun:209) error adding RIO PDF entry: null
#9 Updated by Derik Barseghian over 11 years ago
I was seeing this bug again today on linux and mac. Upgrading to hsqldb 1.8 seems to solve the bug -- I've been unable to get it to occur since doing so on both linux and mac. I'll keep trying.
What do people think about moving Kepler to hsqldb 1.8 at this point?
#11 Updated by Derik Barseghian over 11 years ago
I'd like to move to 1.8 if possible since this bug is going to be pretty bad for users, they'd seemingly have to clean their cache after every third Kepler if they wanted to export "run kars". However it's possible 1.8 is causing a problem with the tpc workflow in bug 4197, so I need to see if that's true first...