Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 357888

Summary: ODA Driver can not be used for reporting on models with null attributes
Product: [Modeling] EMF Reporter: John Conlon <jconlon>
Component: CoreAssignee: Kenn Hussey <Kenn.Hussey>
Status: VERIFIED FIXED QA Contact: Kenn Hussey <Kenn.Hussey>
Severity: normal    
Priority: P3 Flags: Kenn.Hussey: indigo+
Version: unspecified   
Target Milestone: SR2   
Hardware: PC   
OS: Linux   
Whiteboard:
Attachments:
Description Flags
Checks for nulls
none
proposed changes none

Description John Conlon CLA 2011-09-15 17:36:09 EDT 
Build Identifier: Build id: 20110615-0604

EMF ODA Driver can not be used to query model instances when results may have EObjects with attributes that return nulls. All queries returning a EObject that has a null attribute will throw a NPE in a dialog:

null
Error
Thu Sep 15 14:24:59 CDT 2011
An unexpected internal exception occurred. Please see log for detail.

org.eclipse.birt.report.designer.core.runtime.GUIException: Caused by java.lang.NullPointerException.
	at org.eclipse.birt.report.designer.core.runtime.GUIException.createGUIException(GUIException.java:78)
	at 
...

Caused by: java.lang.NullPointerException
	at org.eclipse.emf.oda.ecore.impl.ResultSet.getDouble(ResultSet.java:361)
	at org.eclipse.datatools.connectivity.oda.consumer.helper.OdaResultSet.getDouble(OdaResultSet.java:378)
	at )
org.eclipse.birt.data.engine.odaconsumer.ResultSet.getDouble(ResultSet.java:246)
	at org.eclipse.birt.data.engine.odaconsumer.ResultSet.fetch(ResultSet.java:174)
	
...

Note: the Interim datatools driver allowed columns to be set to String Types which would cause attributes with nulls to show up as empty Strings.  Interim driver could also ignore columns altogether and the designer could create computed columns to deal with null attributes.  
If Output Column types were set to the native object types in the Interim datatools driver, null attributes in results would evoke a detailed dialog of which column was causing the problem.

In the new EMF Driver Output Columns can not be ignored and editing the Output Columns to String types still throws this NPE error. 



Reproducible: Always

Steps to Reproduce:
1. Create a ECore model that contains a collection of EObjects that have a computed attribute with a Double data type but one that always returns a null.
2. Use a model instance as ECore DataSource and create a New ECore DataSet with
query to return collection of EObjects with the computed null attribute.
3. From the DataSet Editor Preview Results
Comment 1 John Conlon CLA 2011-09-28 13:20:56 EDT 
Created attachment 204205 [details]
Checks for nulls

This just checks the values for nulls and just returns the null before attempting any casts.
Comment 2 Ed Merks CLA 2011-09-28 14:37:10 EDT 
I don't know all the context, but null should be valid only for EDoubleObject not for EDouble.  So if the data can contain null, it really shouldn't be using EDouble as the type but rather EDoubleObject.  Same goes for all the primitive types...
Comment 3 Kenn Hussey CLA 2011-09-28 14:56:52 EDT 
Yeah, the problem is with cases where we try to "auto box" object types to their primitive counterparts. I'd like to approach the solution a little differently; will attach a patch soon.
Comment 4 Kenn Hussey CLA 2011-09-28 15:23:11 EDT 
Created attachment 204218 [details]
proposed changes

Please confirm whether this patch addresses the issues.
Comment 5 Ed Merks CLA 2011-09-28 15:44:09 EDT 
Is it correct/intended that for types that do support null (the wrappers for primitive numeric types), you nevertheless convert to a wrapped zero value?  If yes, then why not do that for BigDecimal?
Comment 6 John Conlon CLA 2011-09-28 16:19:18 EDT 
(In reply to comment #4)
> Created attachment 204218 [details]
> proposed changes
> 
> Please confirm whether this patch addresses the issues.

Yes, this works.
Comment 7 John Conlon CLA 2011-09-28 16:30:06 EDT 
(In reply to comment #5)
> Is it correct/intended that for types that do support null (the wrappers for
> primitive numeric types), you nevertheless convert to a wrapped zero value?  If
> yes, then why not do that for BigDecimal?

For object like BigDecimal, I think that null would be preferred as it seems that BIRT, would just leave a blank in the report.  Something one wants if there was no value set in the model. 

But instead of 0 in the case of Double and the wrapped primitive double should we instead return a NaN if the value was null?
Comment 8 Kenn Hussey CLA 2011-09-28 22:10:58 EDT 
(In reply to comment #5)
> Is it correct/intended that for types that do support null (the wrappers for
> primitive numeric types), you nevertheless convert to a wrapped zero value?  If
> yes, then why not do that for BigDecimal?

For anything that has a primitive return type (rather than a wrapped one), I return the default value for that type in the case of a null value; in all other cases (i.e., where the return type is an object), I return null.
Comment 9 Kenn Hussey CLA 2011-09-28 22:13:55 EDT 
(In reply to comment #7)
> But instead of 0 in the case of Double and the wrapped primitive double should
> we instead return a NaN if the value was null?

It seemed better to me to be consistent about how we treat primitive return values for null attributes, i.e., to return the default value for the primitive. I believe clients are expected to use the wasNull() method to determine whether a value ended up the way it is because the source value was null...
Comment 10 Kenn Hussey CLA 2011-10-03 11:22:06 EDT 
The fix has been committed to CVS (maintenance and HEAD) and will be available the next builds.
Comment 11 Kenn Hussey CLA 2011-10-03 14:45:27 EDT 
Builds (integration and maintenance) containing this fix are now available.