Bug #4164
closedAssociated Data - wf_exec_id behavior
0%
Description
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!
Files
Related issues
Updated by ben leinfelder almost 15 years ago
i'm not finding this as a problem - changed a bunch of stuff with how files are written and it seems to be happy now.
reopen if needed
Updated by Derik Barseghian almost 15 years ago
I'm seeing this issue again, reopening.
Updated by Derik Barseghian almost 15 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
java.lang.NullPointerException
at java.io.ByteArrayInputStream.<init>(ByteArrayInputStream.java:89)
at org.kepler.kar.handlers.ReportInstanceKAREntryHandler.saveReportInstanceForWorkflowRun(ReportInstanceKAREntryHandler.java:207)
at org.kepler.kar.handlers.ReportInstanceKAREntryHandler.save(ReportInstanceKAREntryHandler.java:111)
at org.kepler.kar.KARBuilder.generateKAR(KARBuilder.java:192)
at org.kepler.workflowrunmanager.gui.WorkflowRunManagerPanel.exportRunsToKAR(WorkflowRunManagerPanel.java:592)
Updated by Derik Barseghian almost 15 years ago
Also once it starts happening, it seems to happen every time, even new kepler instances.
Updated by Derik Barseghian almost 15 years ago
I'm still seeing this in wrp, even after a full clean. It seems to consistently begin happening on the third instance of Kepler, when trying to export runs.
Updated by Derik Barseghian almost 15 years ago
Examples showing weird behavior of selects on associated_data table
Updated by Derik Barseghian almost 15 years ago
I'm unable to get this bug to occur today...but Dan was seeing it today.
Updated by Derik Barseghian almost 15 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?
Updated by Chad Berkley almost 15 years ago
If you're sure that updating isn't going to break anything, go for it. If there is any doubt, don't do it.
Updated by Derik Barseghian almost 15 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...
Updated by Derik Barseghian almost 15 years ago
I checked in hsqldb 1.8 in r19734 and that seems to fix this problem. Closing.