nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

conditional output of content

andreas2

Hi, 
 
I was designing some reports heavily based on the "visibility" feature of e.g. table rows. 
Wondering why my already long running reports got worse in an almost exponential degree relative to the query returns I put some logging in place and recognized, that the visibility (although set to hide->for all outputs->"true" or "false" based on some outer table content) is only effects the rendering and not the run phase. 
 
RPTDESIGN: This means e.g. the following (correct me please if I am wrong), abstractly speaking: 
<pre class='_prettyXprint _lang-auto _linenums:0'>
<birttable query="select some_bool from some_table"> 

<detailrow id=1 visibilityHideRule="some_bool == 1" visibilityForOutput="all">
<td> <birttext> detail 1 content <birttable query="...subquery 1..." /> </birttext> </td>
</detailrow>

<detailrow id=2 visibilityHideRule="some_bool == 0" visibilityForOutput="all">
<td> <birttext> detail 2 content <birttable query="...subquery 2..." /> </birttext> </td>
</detailrow>

</birttable>
</pre>
 
Now let's assume the result of the outer table query is: 
 
<pre class='_prettyXprint _lang-auto _linenums:0'>
some_bool

0
1
</pre>
 
and the outputted table rows will not be sorted in some way (to keep it easy). 
Which means we will get two rows outputted in the end ("rendered") ... no problem so far, but obviously 4 rows will get generated in the RUN phase ... 
 
RPTDOCUMENT/RUN phase=> the above will be transformed to something like the following: 
 
<pre class='_prettyXprint _lang-auto _linenums:0'>
<table>



<tr id=1 visibilityHideRule="0 == 1" visibilityForOutput="all">
<td> detail 1 content <table>...subquery 1.1 results...</table> </td>
</tr>
<tr id=2 visibilityHideRule="0 == 0" visibilityForOutput="all">
<td> detail 2 content <table>...subquery 2.1 results...</table> </td>
</tr>



<tr id=1 visibilityHideRule="1 == 1" visibilityForOutput="all">
<td> detail 1 content <table>...subquery 1.2 results...</table> </td>
</tr>
<tr id=2 visibilityHideRule="1 == 0" visibilityForOutput="all">
<td> detail 2 content <table>...subquery 2.2 results...</table> </td>
</tr>

...

</table>
</pre>
 
 
HTML/PDF/RENDER phase the above will be finally transformed to something like the following: 
 
<pre class='_prettyXprint _lang-auto _linenums:0'>
<table>

<tr id=2 >
<td> detail 2 content <table>...subquery 2.1 results...</table> </td>
</tr>

<tr id=1 >
<td> detail 1 content <table>...subquery 1.2 results...</table> </td>
</tr>

...

</table>
</pre>
 
 
My problem here is: 
<pre class='_prettyXprint _lang-auto _linenums:0'>subquery 1.2</pre> and <pre class='_prettyXprint _lang-auto _linenums:0'>subquery 2.1</pre> are executed and processed (which may take a long time depending on your special report) although we know already in the RUN phase that they will never be output :-( 
 
Is there a straight forward way to handle that or is this more like a BIRT feature/bug? 
 
The only feasible but ugly solution I can see so far is to use scripting and explicitely coding the "visibility" into the subqueries with something like <pre class='_prettyXprint _lang-auto _linenums:0'>select ... where 1 = :visible</pre>. 
So the DB optimizer should not spend much time to execute the query if it is <pre class='_prettyXprint _lang-auto _linenums:0'>select ... where 1=0</pre>. 
 
Kind regards 
Andreas :-) 
 
-- 
I am using BIRT 2.6 (Eclipse Helios) and try putting this out to some PDF.

Find more posts tagged with

Comments

Hans_vd

Hi Andreas 
 
 
<blockquote class='ipsBlockquote' >...or is this more like a BIRT feature/bug? </blockquote>
Not wanting to see the data, is not the same as not wanting to get the data. I can perfectly imagine some situations where you have 2 tables based on 1 dataset, where you want one of the tables to be displayed and the other one hided. So I'd say feature, not bug 
 
<blockquote class='ipsBlockquote' >The only feasible but ugly solution I can see so far is to use scripting and explicitely coding the "visibility" into the subqueries with something like </blockquote>
As far as I can see, the results of the outer table are coming from a query. Passing the result of a dataset to input parameter of another dataset is a very common way to achieve this kind. Not ugly at all:-) 
 
Hope this helps 
H.

andreas2

Hi Hans, 
 
thanks for the quick reply. 
 
Regarding the "visibility"/hide/all: I also see it more like a feature than a bug, but it does not what I would expect from it in the first place. 
 
<blockquote class='ipsBlockquote' data-author="'Hans_vd'" data-cid="68950" data-time="1285931366" data-date="01 October 2010 - 04:09 AM">
As far as I can see, the results of the outer table are coming from a query. Passing the result of a dataset to input parameter of another dataset is a very common way to achieve this kind. Not ugly at all:-) </blockquote>
 
Maybe we misunderstood here since it's still ugly in my opinion when you still generate the always hidden content with the difference, that some sub table(s) do not have entries where they had before. 
 
before with visibility settings always disabled for tr (regarding RPTDOCUMENT/RUN results): 
<pre class='_prettyXprint _lang-auto _linenums:0'><t1> <tr hideForAllOutputs="true"> foo bar <t1.1> ... 200 data rows with headings, subcontents etc.</t1.1> </tr> bla blu </t1></pre>
 
ugly workaround that only fixes the long running t1.1 query: 
<pre class='_prettyXprint _lang-auto _linenums:0'><t1> <tr hideForAllOutputs="true"> foo bar <t1.1> ... 0 data rows still with headings </t1.1> </tr> bla blu </t1></pre>
 
what I would like to see if hide is set to true for all outputs (in this case for my tr): 
<pre class='_prettyXprint _lang-auto _linenums:0'><t1> </t1></pre>
 
Regards 
Andreas :-)

thuston

You need to Filter sooner so the section is not created.
Setting to not Visible can be conditional on the output format. Even when you select 'Hide for all' it assumes you have some reason for allowing the data to be used in the table.

andreas2

<blockquote class='ipsBlockquote' data-author="'thuston'" data-cid="68960" data-time="1285939682" data-date="01 October 2010 - 06:28 AM">
You need to Filter sooner ... </blockquote>
 
... and this means ugly workarounds so far I can see it :-/ 
 
Maybe I should explain what I do and that this is not some extraordinary use case... 
 
Monitoring report for machines with a structure like this: 
 
<pre class='_prettyXprint _lang-auto _linenums:0'>
- machine 1
- CPU Usage (includes some text, a chart, some aggregated values)
- Memory Usage (same as above)
- Swap Usage ...
- Network Usage ...
- DB Usage
- DB Instance 1
- Tablespace Usage
- Tablespace 1
- ...
- DB Memory Usage
- ....
- DB Instance 2
- ...
- ...
- machine 2
- ...
- ...
</pre>
 
the design is as follows (abstract): 
 
<pre class='_prettyXprint _lang-auto _linenums:0'>
<table querySelectColumns="machine|usage group">

<grpcol level=1 groupby="machine">...machine name...</grpcol> 
<grpcol level=2 groupby="usage group" hide="usage group != 'Memory Usage'>...memory usage details...</grpcol>
<grpcol level=2 groupby="usage group" hide="usage group != 'CPU Usage'>...memory usage details...</grpcol>
<grpcol level=2 groupby="usage group" ...
...
</table>
</pre>
workaround 1: i need the groups for a nice hierarchical PDF content map generation, but could also use a detail row otherways 
 
So the various queries in the grpcol level=2 levels are heavy and should not be executed if not output. 
 
If you know a better way to solve my problem any help would be much appreciated - I may be already blind for a straight forward solution :-) 
 
Kind regards 
Andreas :-) 
 
 
PS: Another bad thing (it would be another topic) is that with this implementation the filters I sat on the lower levels only work in memory and are not automatically applied to the query itself (I know this is not easy from the framework perspective). So I already had to do some scripting (which I don't like due to maintainability) to filter the data on the query level. Imagine some hundred machines and all their data processed by BIRT in memory and queried again and again due to sorting, filtering, grouping, aggregation ...

thuston

Can you zip and post your design? I'm not getting why you need so many groupHeaders but only show one.
Does each have its own nested Table with unique query? Isn't it possible to parameterize the nested query and only have one GroupHeader row?

andreas2

<blockquote class='ipsBlockquote' data-author="'thuston'" data-cid="68974" data-time="1285944637" data-date="01 October 2010 - 07:50 AM">
Can you zip and post your design? </blockquote>
 
Unfortunately I can't post it due to its customer value. If it would be really necessary I could prepare and post a skeleton version of it, but I don't think it's necessary right now. 
 
<blockquote class='ipsBlockquote' >
I'm not getting why you need so many groupHeaders but only show one. </blockquote>
 
I explained it in the workaround above: the PDFs content pane (left side in most viewers) can be hierarchically nested: 
 
<pre class='_prettyXprint _lang-auto _linenums:0'>
- machine 1
+ Memory Usage
+ Network Usage
+ ...
+ machine 2
+ machine 3
</pre>
 
BIRT only generates this hierarchy in PDFs on table groups. That's the only reason... 
 
<blockquote class='ipsBlockquote' >
Isn't it possible to parameterize the nested query and only have one GroupHeader row? </blockquote>
 
But then I think the problem is still the same with multiple detail rows and their different visibility. 
Of course I could have all the different subsections in one outer detail row. If there would be no database on a machine the query should return fast in the optionally hidden DB Usage section and the whole thing would be solved. 
But in the end we want all the advantages ... nice PDF content pane and reasonably fast running report. 
 
Maybe everything would be easier if I have a look how to solve the PDF content pane problem via scripting if possible. :-) 
 
<blockquote class='ipsBlockquote' >
Does each have its own nested Table with unique query? </blockquote>
 
Yes. Highly individual content. 
 
Regards 
Andreas :-)