Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Intelligence (Analytics)
Performance implications of creating column bindings for table footer
EricB
Hi All,
Just thought I'd share my experience with displaying data in the footers of tables. What I found is that columns which are not explicitly 'Aggregate' types will get computed for every single record in the Table. This may seem obvious, but it caught us by surprise when creating column bindings to manipulate aggregate values.
We have a table of Space records where Space has an 'Area' column. In the footer of the table, we want to display a formatted value of the total area of all Spaces in the table. We first created an aggregate SUM column binding to total the area and then next we created a column binding to manipulate (via expression) that aggregate in to the format we want to display in the footer.
What we found was that the expression to manipulate the aggregate in to a String was computed once for every single record in the table even though it was going to compute to the same value every time. I think this makes sense since BIRT really can't know it's going to compute to the same value every time. After this experience, though, it does feel a bit weird that that footer 'Columns' coexist in the same group of column bindings as the detail Columns. It's possible we're going about this all the wrong way... if that's the case, any feedback would be appreciated.
I'd be interested if other people have encountered this and, if so, what they've done to avoid it. What I ended up doing was nesting a dummy table inside the Space footer and putting my formatting expression in the footer of that dummy table. It could refer to the aggregate in the parent Space table, but it would only be executed a single time since the dummy table didn't have results.
Thanks,
Eric
Find more posts tagged with
Comments
mwilliams
So, you created an aggregation in the binding tab for the table and then used a data element to display the aggregation? If so, did you try just dragging the aggregation element in from the palette and using it instead. Not sure how different this will act. Otherwise, you could just put a text or dynamic textbox in your table footer to display the aggregation value and format it in script or using the format= option in the text box.
EricB
<blockquote class='ipsBlockquote' data-author="'mwilliams'" data-cid="83983" data-time="1318362042" data-date="11 October 2011 - 12:40 PM"><p>
So, you created an aggregation in the binding tab for the table and then used a data element to display the aggregation? If so, did you try just dragging the aggregation element in from the palette and using it instead. Not sure how different this will act. Otherwise, you could just put a text or dynamic textbox in your table footer to display the aggregation value and format it in script or using the format= option in the text box.<br /></p></blockquote>
That helped so much. Using 'Dynamic Text' instead of 'Data' was a much better option. I didn't realize the implications of using one vs. the other.<br />
<br />
Thanks,<br />
<br />
Eric
mwilliams
You're welcome! Let us know whenever you have questions!