Home » Archived » BIRT » Nested table dataset cache
Nested table dataset cache [message #644949] |
Tue, 14 December 2010 17:48  |
Eclipse User |
|
|
|
Is there any way to have a nested table filter based on a secondary
dataset - without having to query the database one time for each row in
the parent table?
I am trying to use a filter on the nested table instead of a dataset
parameter:
row['customer_id'] == row._outer['customer_id']
Even though the dataset query for the nested table doesn't change, the
query is still going to the database for each row. Can this data be
cached and reused somehow?
|
|
| | | | | |
Re: Nested table dataset cache [message #645175 is a reply to message #645145] |
Wed, 15 December 2010 14:14   |
Eclipse User |
|
|
|
I was able to recreate the problem with a simple query. If the outer
table (using same dataset as inner) returns 0 rows using the query, it
will run over and over for each row in the middle table. This is
probably happening because the cache appears to be empty. I was able to
fix it in my case by adding a dummy row that always returns and will be
filtered out. Is this considered a bug?
Thanks for you help!
On 12/15/2010 12:03 PM, Pinny Markowitz wrote:
> I recreated the scenario you provided and it worked as you said. Adding
> filters or nesting within group rows worked as well. For some reason I'm
> not seeing this behavior in my own report, which is significantly more
> complex. I'll do some more research to see if I can determine where it
> is coming from.
>
> Thanks!
>
> On 12/15/2010 11:20 AM, Jason Weathersby wrote:
>> Pinny,
>>
>> The last report I posted did not call the query every time. The outer
>> most table was bound to the same dataset as the innermost table. The
>> only difference was that is was not filtered.
>>
>> Jason
>>
>>
>>
>> On 12/15/2010 10:39 AM, Pinny Markowitz wrote:
>>> Jason
>>>
>>> Thanks for responding. Yes, I am using a separate dataset for the nested
>>> table, and using the solution you proposed I am still seeing the
>>> database being queried for each row in the parent table.
>>>
>>> A join on the datasets isn't practical since each set holds quite a bit
>>> of detailed data that the other does not. I was actually nesting the
>>> second dataset within a group footer of the parent table because of
>>> this.
>>>
>>> Do you know of any other approach that might work? Also, is there a
>>> reason that BIRT doesn't allow filtering on bound report items? Thanks!
>>>
>>> On 12/14/2010 7:44 PM, Jason Weathersby wrote:
>>>> One method I tried was to take the dataset used in the inner query and
>>>> bind it to a table and delete everything in the table but the footer
>>>> row
>>>
>>
>
|
|
|
Re: Nested table dataset cache [message #645176 is a reply to message #645175] |
Wed, 15 December 2010 14:18   |
Eclipse User |
|
|
|
Not sure if its a bug, but log it anyways and we may be able to pick it
up as an enhancement.
Jason
On 12/15/2010 2:14 PM, Pinny Markowitz wrote:
> I was able to recreate the problem with a simple query. If the outer
> table (using same dataset as inner) returns 0 rows using the query, it
> will run over and over for each row in the middle table. This is
> probably happening because the cache appears to be empty. I was able to
> fix it in my case by adding a dummy row that always returns and will be
> filtered out. Is this considered a bug?
>
> Thanks for you help!
>
> On 12/15/2010 12:03 PM, Pinny Markowitz wrote:
>> I recreated the scenario you provided and it worked as you said. Adding
>> filters or nesting within group rows worked as well. For some reason I'm
>> not seeing this behavior in my own report, which is significantly more
>> complex. I'll do some more research to see if I can determine where it
>> is coming from.
>>
>> Thanks!
>>
>> On 12/15/2010 11:20 AM, Jason Weathersby wrote:
>>> Pinny,
>>>
>>> The last report I posted did not call the query every time. The outer
>>> most table was bound to the same dataset as the innermost table. The
>>> only difference was that is was not filtered.
>>>
>>> Jason
>>>
>>>
>>>
>>> On 12/15/2010 10:39 AM, Pinny Markowitz wrote:
>>>> Jason
>>>>
>>>> Thanks for responding. Yes, I am using a separate dataset for the
>>>> nested
>>>> table, and using the solution you proposed I am still seeing the
>>>> database being queried for each row in the parent table.
>>>>
>>>> A join on the datasets isn't practical since each set holds quite a bit
>>>> of detailed data that the other does not. I was actually nesting the
>>>> second dataset within a group footer of the parent table because of
>>>> this.
>>>>
>>>> Do you know of any other approach that might work? Also, is there a
>>>> reason that BIRT doesn't allow filtering on bound report items? Thanks!
>>>>
>>>> On 12/14/2010 7:44 PM, Jason Weathersby wrote:
>>>>> One method I tried was to take the dataset used in the inner query and
>>>>> bind it to a table and delete everything in the table but the footer
>>>>> row
>>>>
>>>
>>
>
|
|
|
Re: Nested table dataset cache [message #645185 is a reply to message #645176] |
Wed, 15 December 2010 14:54   |
Eclipse User |
|
|
|
https://bugs.eclipse.org/bugs/show_bug.cgi?id=332678
Thanks again!
On 12/15/2010 2:18 PM, Jason Weathersby wrote:
> Not sure if its a bug, but log it anyways and we may be able to pick it
> up as an enhancement.
>
> Jason
>
> On 12/15/2010 2:14 PM, Pinny Markowitz wrote:
>> I was able to recreate the problem with a simple query. If the outer
>> table (using same dataset as inner) returns 0 rows using the query, it
>> will run over and over for each row in the middle table. This is
>> probably happening because the cache appears to be empty. I was able to
>> fix it in my case by adding a dummy row that always returns and will be
>> filtered out. Is this considered a bug?
>>
>> Thanks for you help!
>>
>> On 12/15/2010 12:03 PM, Pinny Markowitz wrote:
>>> I recreated the scenario you provided and it worked as you said. Adding
>>> filters or nesting within group rows worked as well. For some reason I'm
>>> not seeing this behavior in my own report, which is significantly more
>>> complex. I'll do some more research to see if I can determine where it
>>> is coming from.
>>>
>>> Thanks!
>>>
>>> On 12/15/2010 11:20 AM, Jason Weathersby wrote:
>>>> Pinny,
>>>>
>>>> The last report I posted did not call the query every time. The outer
>>>> most table was bound to the same dataset as the innermost table. The
>>>> only difference was that is was not filtered.
>>>>
>>>> Jason
>>>>
>>>>
>>>>
>>>> On 12/15/2010 10:39 AM, Pinny Markowitz wrote:
>>>>> Jason
>>>>>
>>>>> Thanks for responding. Yes, I am using a separate dataset for the
>>>>> nested
>>>>> table, and using the solution you proposed I am still seeing the
>>>>> database being queried for each row in the parent table.
>>>>>
>>>>> A join on the datasets isn't practical since each set holds quite a
>>>>> bit
>>>>> of detailed data that the other does not. I was actually nesting the
>>>>> second dataset within a group footer of the parent table because of
>>>>> this.
>>>>>
>>>>> Do you know of any other approach that might work? Also, is there a
>>>>> reason that BIRT doesn't allow filtering on bound report items?
>>>>> Thanks!
>>>>>
>>>>> On 12/14/2010 7:44 PM, Jason Weathersby wrote:
>>>>>> One method I tried was to take the dataset used in the inner query
>>>>>> and
>>>>>> bind it to a table and delete everything in the table but the footer
>>>>>> row
>>>>>
>>>>
>>>
>>
>
|
|
|
Re: Nested table dataset cache [message #645196 is a reply to message #645185] |
Wed, 15 December 2010 16:24  |
Eclipse User |
|
|
|
Thanks for logging
On 12/15/2010 2:54 PM, Pinny Markowitz wrote:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=332678
>
> Thanks again!
>
> On 12/15/2010 2:18 PM, Jason Weathersby wrote:
>> Not sure if its a bug, but log it anyways and we may be able to pick it
>> up as an enhancement.
>>
>> Jason
>>
>> On 12/15/2010 2:14 PM, Pinny Markowitz wrote:
>>> I was able to recreate the problem with a simple query. If the outer
>>> table (using same dataset as inner) returns 0 rows using the query, it
>>> will run over and over for each row in the middle table. This is
>>> probably happening because the cache appears to be empty. I was able to
>>> fix it in my case by adding a dummy row that always returns and will be
>>> filtered out. Is this considered a bug?
>>>
>>> Thanks for you help!
>>>
>>> On 12/15/2010 12:03 PM, Pinny Markowitz wrote:
>>>> I recreated the scenario you provided and it worked as you said. Adding
>>>> filters or nesting within group rows worked as well. For some reason
>>>> I'm
>>>> not seeing this behavior in my own report, which is significantly more
>>>> complex. I'll do some more research to see if I can determine where it
>>>> is coming from.
>>>>
>>>> Thanks!
>>>>
>>>> On 12/15/2010 11:20 AM, Jason Weathersby wrote:
>>>>> Pinny,
>>>>>
>>>>> The last report I posted did not call the query every time. The outer
>>>>> most table was bound to the same dataset as the innermost table. The
>>>>> only difference was that is was not filtered.
>>>>>
>>>>> Jason
>>>>>
>>>>>
>>>>>
>>>>> On 12/15/2010 10:39 AM, Pinny Markowitz wrote:
>>>>>> Jason
>>>>>>
>>>>>> Thanks for responding. Yes, I am using a separate dataset for the
>>>>>> nested
>>>>>> table, and using the solution you proposed I am still seeing the
>>>>>> database being queried for each row in the parent table.
>>>>>>
>>>>>> A join on the datasets isn't practical since each set holds quite a
>>>>>> bit
>>>>>> of detailed data that the other does not. I was actually nesting the
>>>>>> second dataset within a group footer of the parent table because of
>>>>>> this.
>>>>>>
>>>>>> Do you know of any other approach that might work? Also, is there a
>>>>>> reason that BIRT doesn't allow filtering on bound report items?
>>>>>> Thanks!
>>>>>>
>>>>>> On 12/14/2010 7:44 PM, Jason Weathersby wrote:
>>>>>>> One method I tried was to take the dataset used in the inner query
>>>>>>> and
>>>>>>> bind it to a table and delete everything in the table but the footer
>>>>>>> row
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
|
Goto Forum:
Current Time: Tue Jul 22 11:49:17 EDT 2025
Powered by FUDForum. Page generated in 0.07426 seconds
|