Community
Participate
Working Groups
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
Created attachment 204205 [details] Checks for nulls This just checks the values for nulls and just returns the null before attempting any casts.
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...
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.
Created attachment 204218 [details] proposed changes Please confirm whether this patch addresses the issues.
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?
(In reply to comment #4) > Created attachment 204218 [details] > proposed changes > > Please confirm whether this patch addresses the issues. Yes, this works.
(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?
(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.
(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...
The fix has been committed to CVS (maintenance and HEAD) and will be available the next builds.
Builds (integration and maintenance) containing this fix are now available.
