dealing with null values

[rossi_jeff]

 I my application I have several events tables that store duration in minutes. When the event is in progress the duration is null.

I my report I want to show the text "In Progress" or the formatted value, in csv the formatted value is integer

$V{duration_hours} -> integer

($F{stop_events_duration}.intValue() / 60).intValue()

 

$V{duration_minutes} -> integer

($F{stop_events_duration}.intValue() % 60)

 

$V{duration_hrs_min} -> type string

(($F{stop_events_duration}.equals(null)) || ($V{duration_hours}.equals(null)) || ($V{duration_minutes}.equals(null))) ? "In Progress" : (($V{duration_hours} == 0) ? ($V{duration_minutes}.toString() + " min") : ($V{duration_hours}.toString() + ($V{duration_hours} == 1 ? " hr, " : " hrs, ") + $V{duration_minutes}.toString() + " min"))

 

The textfield in details

($F{stop_events_duration}.intValue() == null) ? "In Progress" : (($P{output_format} == "PDF") ? $V{duration_hrs_min} : ($P{output_format} == "RTF") ? $V{duration_hrs_min} : $F{stop_events_duration}.toString())

 

 

[lknueve]

Are you getting an error message?

[rossi_jeff]

 No the entire expression evaluates to null instead of giving the true value of the ternary expression. 

When I expect "In Progress" I get null

Post Edited by rossi_jeff at 02/25/2011 16:06

[mdahlman]

Perhaps you run into trouble with this line:

$F{stop_events_duration}.intValue() == null

I expect that it makes mores sense to do this:

$F{stop_events_duration} == null

If the field is null, then calling intValue() on it won't work. You need to check on the object itself. Does that change anything?

Regards,
Matt

 

[rossi_jeff]

 No actually I had tried that before.

The issue seems to only occur if the field is an integer, it work fine in other tables where field is a varchar or timestamp.

[mdahlman]

Can you post a minimal .jrxml example that shows the problem? Something like this:

"Expected outcome is 'In Progress':" [some expression using MyIntegerField]
"Expected outcome is 'In Progress':" [analogous expression using MyStringField]

If it's easily reproduceable like that then I expect that it should be easy to fix.

Regards,
Matt

[rossi_jeff]

 $F{MyIntegerField} == null ? "In Progress" : $F{MyIntegerField}.toString()

 $F{MyStringField} == null ? "In Progress" : $F{MyStringField}

 $F{MyTimestampField} == null ? "In Progress" : $F{MyTimestampField}.toString()

[rossi_jeff]

 Solved using MySQL IFNULL function but an issue remain w/ null in integer fields. Should it be reported as a bug?

[mdahlman]

Yes, please report this as a bug.

I can easily reproduce it with your sample. You can attach my .jrxml to the bug report to save having to find your own copy.

It's definitely a bug linked to the upgrade of Groovy. I can switch the report language from Groovy to Java and I get the expected behavior.

Thanks,
Matt

[Teodor Danciu]

Hi,

 

Sorry for my late intervention on this thread, but we were actually aware of this problem and worked to solve in the meantime.

 

The problem appears in Jaspersoft v.4.0 because of a Groovy upgrade we made at that time. The new version of Groovy brought changes in how Groovy expressions work. The most obvious one was with regards to adding numbers.

 

If you have two numbers A and B and you add the with an expression A + B, the results might not be a number.

If A is 3 and B is 5, the result will be the number 8.

If A is 3, but B is null, the result will be null.

If A is null and B is also null, the result will be the String value "nullnull" !!!!!!!!....

And this 3rd case was breaking JR reports due to class cast exceptions, since JR was expecting a number or at least null. But not a String!!!

 

In an unsuccesful attempt in solving this, JR internal Groovy script generator was modified in the hope that forcing a NPE one each of the A and B members in the expression would make JR work exactly like before. Unfortunately, this fix did not take into account expression with the logical operator inside, in which A or B are actually tested for null.

 

I have since reverted the unfortunate fix from JR and tried a different approach. I have now refactored JR so that the type of the expression no longer needs to be declared at report design time. This in turn eliminates all cast operations that JR perfomed on the result of expressions and thus removes the risk of getting a class cast exeption when the Groovy result is not of the type you would expect. This changes are now committed on JR SVN repository and will be part of the JR 4.0.3 version to be released soon.

 

Thank you,

Teodor