[Mike Reidy]

Hello,

I have written an ODA extension for use within BIRT and I have noticed something a bit odd when we recently upgraded from BIRT 3.7.1 to BIRT 3.7.2 and I was wondering if anyone could enlighten me.

In my report I have 2 data sets, data set 1 and data set 2. In my report I use data set 1 to populate rows of a table, data set 2 has a parameter that is bound to the row number of data set 1 and data set 2 in turn populates a table nested at the end of the row generated by data set 1.

Note : In the following explanation the rendering of data set 1 causes generation of result set 1 and rendering data set 2 causes generation of result set 2

With BIRT 3.7.1 I see the following when I do a preview :

result set 1 next() is called followed by complete result set 2 iteration, then followed by subsequent result set 1 next() calls and their associated result set 2 iterations. So process one row of result 1 followed by all rows of data set 2 ie

result set 1 row 1 => result set 2 row 1 (passing row 1 as parameter)
                   => result set 2 row 2 (passing row 1 as parameter)
                   => result set 2 row 3 (passing row 1 as parameter)

result set 1 row 2 => result set 2 row 1 (passing row 2 as parameter)
                   => result set 2 row 2 (passing row 2 as parameter)
                   => result set 2 row 3 (passing row 2 as parameter)

result set 1 row 3 => result set 2 row 1 (passing row 3 as parameter)
                   => result set 2 row 2 (passing row 3 as parameter)
                   => result set 2 row 3 (passing row 3 as parameter)

With BIRT 3.7.2 I see something different :

result set 1 is completely iterated and each of the result set 2 result sets are then made ie.

result set 1 row 1 
result set 1 row 2 
result set 1 row 3

result set 2 row 1 (passing row 1 as parameter)
result set 2 row 2 (passing row 1 as parameter) 
result set 2 row 3 (passing row 1 as parameter)

result set 2 row 1 (passing row 2 as parameter)
result set 2 row 2 (passing row 2 as parameter)
result set 2 row 3 (passing row 2 as parameter)

result set 2 row 1 (passing row 3 as parameter)
result set 2 row 2 (passing row 3 as parameter)
result set 2 row 3 (passing row 3 as parameter)

Now my questions;

1. which of these is this expected behavior? Are there any guarantees of the result set traversal behavior?
2. is there a way to control this behavour?

[Mike Reidy]

Just a short follow up on this; it would appear that the difference is down to the creation of a SimpleResultSet in the DataSourceQuery class. In 3.7.1 I am getting a SimpleResultSet (because my query execution strategy appears to be SimpleNoLookingFoward) in 3.7.2 I am getting a CachedResultSet.

Can someone explain this to me? Please.

[JasonW]

Mike,

Take a look at this bugzilla id:
https://bugs.eclipse...g.cgi?id=364631

I wonder if this is the issue. Change the setting in the advanced section on the dataset.

Jason

[Mike Reidy]

Thanks, that setting has no effect on what I am seeing, but I did debug a little further and I saw the following code in QueryExecutionStrategyUtil. As a result of this change I am getting a Complex strategy type all the time and never using a SimpleResultSet.

        public static Strategy getQueryExecutionStrategy( DataEngineSession session, IQueryDefinition query,
			IBaseDataSetDesign dataSet ) throws DataException
	{
		SortingOptimizer opt = new SortingOptimizer( dataSet, query );

		// for ted 43040 disable progressive viewing, will fix this problem in 11sp4M2
		if ( session.getEngineContext( ).getMode( ) == DataEngineContext.DIRECT_PRESENTATION )
		{
			return Strategy.Complex;
		}
....

This looks like a temporary fix? Was this meant to be released into 3.7.2?

JasonW, on 12 April 2012 - 12:23 PM, said:

Mike,

Take a look at this bugzilla id:
https://bugs.eclipse...g.cgi?id=364631

I wonder if this is the issue. Change the setting in the advanced section on the dataset.

Jason

[JasonW]

I am not certain. Have you checked the Juno code (June 2012 release)? Can you open a bugzilla to get suggestions. BTW looking at the ODA data could you use nested tables instead?

Jason

[Mike Reidy]

Looked at BIRT_3_8_0 and master branches and both would appear to have the same code. I have raised a JIRA to get this fixed.

[JasonW]

Thanks for logging it Mike.

Jason