Proper way to access data in a DataSet

This started because we were getting the 
<pre class='_prettyXprint _lang-auto _linenums:0'>RHINO USAGE WARNING: Missed Context.javaToJS() conversion:</pre>
in some of our reports, and the result was that in a very short time, we'd see a log file of almost a gig in size. After troubleshooting the issue, it appears that when the report writer accesses our scripted dataset, checking for null in an expression, then the issue happens. 
 
For example, in our report, if an expression uses the dataSetRow fields directly, and this causes the RHINO USAGE WARNING. 
<pre class='_prettyXprint _lang-auto _linenums:0'>if (dataSetRow["triContract__triStandardContract____triNameTX"] == null) {
"NULL";
} else {
"NOT NULL";
}
</pre>
 
But, another developer noted, that if we use a column binding to map the dataSetRow, and the expression utilizes the row object instead of the dataSetRow object, then there is no expression warning. 
<pre class='_prettyXprint _lang-auto _linenums:0'>if (row["triContract__triStandardContract____triNameTX"] == null) {
"NULL";
} else {
"NOT NULL";
}
</pre>
 
Our databset doesn't return native types like, int, boolean or String, but rather we return an object type that wraps the native value. (We do this for various reasons, so I won't get into the why, but we can't really change that). 
 
What I'm seeing though, is that BIRT is not consistent in how it evaluates the expression, and in once case, it generates the RHINO error and in the other, it does not. Is this a bug? Should we ALWAYS use the second method and never access the dataSetRow directly? 
 
I can attach the 2 sample reports, if you like, although, you can't really run them, since they require our scripted dataset. 
 
Thanks for any guidance on this. 
 
Sean.

Find more posts tagged with

Comments

mwilliams

Sean,

In what expression are you using this? Are you needing to access the dataSet directly for a reason? Really, the only reasons to use dataSetRow are if you've made changes to the binding in your element and you want the original, unaltered binding from the dataSet in this particular instance. Or if you're creating a new binding for the table that doesn't currently exist, so you must go to the dataSet directly to create it. Otherwise, if the binding is already created in your table and you haven't altered it in a way that would keep you from wanting to use it, you should probably just use "row".

Hope this helps.

stuckless

Thanks for the reply, it helps alot. To be honest, I'm not sure why I'd accessing the dataset directly (I'm new to the report design aspect of BIRT) I was looking for clarification on the proper way to access the data, and you've pointed that out, so thanks.

EricB

<blockquote class='ipsBlockquote' data-author="'mwilliams'" data-cid="83106" data-time="1316607494" data-date="21 September 2011 - 05:18 AM">
Sean, 
 
In what expression are you using this? Are you needing to access the dataSet directly for a reason? Really, the only reasons to use dataSetRow are if you've made changes to the binding in your element and you want the original, unaltered binding from the dataSet in this particular instance. Or if you're creating a new binding for the table that doesn't currently exist, so you must go to the dataSet directly to create it. Otherwise, if the binding is already created in your table and you haven't altered it in a way that would keep you from wanting to use it, you should probably just use "row". 
 
Hope this helps. </blockquote>
 
Hi mwilliams, 
 
That does help. Unfortunately, the "horse is out of the barn" meaning that we now have a lot of reports with the expression built in this way. Going forward, we will certainly build expressions with row-access in favor of the dataSetRow-access. Until we fully refactor to use 'row' in the expressions, my follow-up question is... what is the consequence (other than the warning) of using the dataSetRow? Is it possible the expressions that utilize the dataSetRow would not yield the appropriate results? In our testing, it seem there's no impact (i.e. it produces the correct results), but I was wondering if you knew something more reliable than our anecdotal evidence. 
 
Thanks, 
 
Eric

johnw

There isn't really any consequences of using dataSetRow instead of row, but you lose some ability in doing so. Not sure why you're getting a log message about that, but that is the only real consequence of keeping them as dataSetRow. When you use dataSetRow, you are getting the data directly from the data set. If you look at the bindings on your table (which creates the row[] objects), they are using dataSetRow. What you get by using row instead is the ability to manipulate that data before it is displayed.

For example, lets say you have a data set that has a status column, and statuses are 0 for incomplete, 1 for complete, and 2 for in progress. If you use dataSetRow, that column will always display 0, 1, 2. If you use row, you can write a simple expression for your binding that does something like:

switch (dataSetRow["status"])
{
case 0:
"Incomplete";
case 1:
"Complete";
case 2:
"In Progress";
}

Then, you can use row["status"] to display the translations. You could use a Map to do the same thing, but I wanted to illustrate a point. Where would this have real world use? If you take a look at the ResourceBundle example I just posted in dev-share, you could localize those strings. You won't be able to do that using dataSetRow since it accesses raw data.

To summarize, dataSetRow will access the raw data directly from the data set. row will access the data bindings created on the container, and allows you to add calculations to change the output. A rule of thumb that I use, never use dataSetRow unless you are creating a binding. Use row whenever possible, and leave the direct row -> dataset bindings alone. If you need to change something, either create a new binding, or use a Dynamic Text element if that new binding won't be re-used.

EricB

<blockquote class='ipsBlockquote' data-author="'johnw'" data-cid="83193" data-time="1316732278" data-date="22 September 2011 - 03:57 PM">
There isn't really any consequences of using dataSetRow instead of row, but you lose some ability in doing so. Not sure why you're getting a log message about that, but that is the only real consequence of keeping them as dataSetRow. When you use dataSetRow, you are getting the data directly from the data set. If you look at the bindings on your table (which creates the row[] objects), they are using dataSetRow. What you get by using row instead is the ability to manipulate that data before it is displayed. 
 
For example, lets say you have a data set that has a status column, and statuses are 0 for incomplete, 1 for complete, and 2 for in progress. If you use dataSetRow, that column will always display 0, 1, 2. If you use row, you can write a simple expression for your binding that does something like: 
 
switch (dataSetRow["status"]) 
{ 
case 0: 
"Incomplete"; 
case 1: 
"Complete"; 
case 2: 
"In Progress"; 
} 
 
Then, you can use row["status"] to display the translations. You could use a Map to do the same thing, but I wanted to illustrate a point. Where would this have real world use? If you take a look at the ResourceBundle example I just posted in dev-share, you could localize those strings. You won't be able to do that using dataSetRow since it accesses raw data. 
 
To summarize, dataSetRow will access the raw data directly from the data set. row will access the data bindings created on the container, and allows you to add calculations to change the output. A rule of thumb that I use, never use dataSetRow unless you are creating a binding. Use row whenever possible, and leave the direct row -> dataset bindings alone. If you need to change something, either create a new binding, or use a Dynamic Text element if that new binding won't be re-used. </blockquote>
 
Thanks johnw! That puts my mind at ease about our existing reports and provides me some good guidelines for our future report development. 
 
Thanks, 
 
Eric

mwilliams

Sorry if I made you worry about it. I didn't mean that you had done anything wrong. I probably should have elaborated more, but it looks like John took care of that for me.

I, like John, am not sure why you'd get a log message.

EricB

<blockquote class='ipsBlockquote' data-author="'mwilliams'" data-cid="83197" data-time="1316736927" data-date="22 September 2011 - 05:15 PM">
Sorry if I made you worry about it. I didn't mean that you had done anything wrong. I probably should have elaborated more, but it looks like John took care of that for me.

I, like John, am not sure why you'd get a log message. </blockquote>
No worries. Thanks to both you and John for the quick assistance. Until we get all our reports to using 'row', we'll need to suppress the WARN message. 
 
-Eric