Queued Tasks Question

[TimK2015]

The runtime column on queued tasks is blank on two of my HDR Fox T2s and seems to be after an update to SQLite this morning. The tasks are completing OK and there is time mentioned in the log column for some tasks.

Can anyone shed any light on this?

 

[peterworks]

Same here...

 

[TimK2015]

In the Database Browser I can see that in the runtime column every entry contains 1.0

The start, submitted and last columns appear to have valid data, i.e. the last value is larger than the start value

 

[prpr]

Flamin' 'eck - there's always something to catch you out isn't there?
The data in the database appears to be correct:

# sqlite3 /mod/etc/queue.db "select runtime from queue"
368.836
16.547
47.22
2.586

But doing the same operation in jim gives this:

# jimsh
Welcome to Jim version 0.83
. package require sqlite3
1.0
. set db [sqlite3.open /mod/etc/queue.db]
::sqlite.handle4
. $db query {select runtime from queue}
{runtime 1.0} {runtime 1.0} {runtime 1.0} {runtime 1.0}
.

although sometimes it shows {runtime 0.0} for whatever reason.
I haven't yet got any further.

 

[MymsMan]

Flamin' 'eck - there's always something to catch you out isn't there?
The data in the database appears to be correct:

# sqlite3 /mod/etc/queue.db "select runtime from queue"
368.836
16.547
47.22
2.586

But doing the same operation in jim gives this:

# jimsh
Welcome to Jim version 0.83
. package require sqlite3
1.0
. set db [sqlite3.open /mod/etc/queue.db]
::sqlite.handle4
. $db query {select runtime from queue}
{runtime 1.0} {runtime 1.0} {runtime 1.0} {runtime 1.0}
.

although sometimes it shows {runtime 0.0} for whatever reason.
I haven't yet got any further.

But the problem is in either the sqlite3 or jim package rather than webif but very strange that it only appears to affect this field, is it the only non-integer number field?

 

[prpr]

But the problem is in either the sqlite3 or jim package

Must be the former as that's what's changed.

rather than webif

It could be worked around in the Webif by converting to text (as jim doesn't care):

. $db query {select cast(runtime as numeric) from queue limit 1}
{{cast(runtime as numeric)} 0.0}
. $db query {select cast(runtime as real) from queue limit 1}
{{cast(runtime as real)} 0.0}
. $db query {select cast(runtime as integer) from queue limit 1}
{{cast(runtime as integer)} 368}
. $db query {select cast(runtime as text) from queue limit 1}
{{cast(runtime as text)} 368.836}
. $db query {select cast(runtime as blob) from queue limit 1}
{{cast(runtime as blob)} 368.836}
. $db query {select cast(runtime as none) from queue limit 1}
{{cast(runtime as none)} 0.0}

but very strange that it only appears to affect this field, is it the only non-integer number field?

The 1.0 only appears for the first query. Subsequent ones all generate 0.0.
It seems to be floating point numbers that cause the problem - possibly that's the only one (until somebody finds another). TBH, I don't know why it's not just converted to an integer before it get written to the DB - the field is declared as an integer both there and in the Jim queue class, but nothing seems to care too much about types - weakly typed languages drive me mad. Changing the column type in the DB makes no difference.

I'll have to write a test program to emulate what the Jim Sqlite extension does to prove it's in Sqlite and then go from there. It's probably an HDR specific problem, but I'd need to compile the Sqlite code on a proper PC to be able to even trace where it goes in a debugger to see what the cause might be.
It's all rather dull and time consuming though.

 

[prpr]

This should now be resolved with the latest package update - 3.52.0.