It’s frustrating that this works in Avatica but fails here because of 
copy-pasted code.

In Avatica, AbstractCursor.IntAccessor already does the right thing — getInt() 
gets the underlying value, casts to Integer, returns 0 if the value is null. 
And getLong() just calls getInt() and implicitly casts int to long.

The Drill driver should have provided an implementation of 
AbstractCursor.Getter suitable for Drill’s vectors and not created its own 
accessors.

Julian

On Sep 23, 2014, at 11:39 AM, Jacques Nadeau <[email protected]> wrote:

> Sounds like a great idea!  We actually already do this for the
> stream/reader interfaces.  I think we should follow Java implicit rules for
> what is allowed.  Plus maybe support the String value functions for
> everything.
> 
> Please open a JIRA.  We look forward to the contribution.
> 
> On Tue, Sep 23, 2014 at 9:29 AM, Matthew Burgess <[email protected]>
> wrote:
> 
>> All,
>> 
>> Is there any interest in being able to "promote" SQL types where prudent,
>> such as being able to call getLong() on an IntAccessor without it throwing
>> an IllegalAccessException?
>> 
>> I ran into this problem while integrating the Drill JDBC driver with
>> Pentaho
>> Data Integration (PDI). I'll be writing a bug report against PDI as well,
>> as
>> we will call whatever getXYZ() method that corresponds to the PDI types.
>> For
>> example, the "Integer" type in PDI maps to a SQL Long value, so PDI calls
>> getLong(), which in Drill (for a SQL INT type) will throw the
>> aforementioned
>> exception. I believe that PDI should handle this kind of promotion by
>> checking getColumnType(), but also I would think that Drill would implement
>> things like getLong() on IntAccessor and "promote" the Integer value to a
>> Long value.
>> 
>> Is this done on purpose in Drill (i.e. not overriding certain methods from
>> AbstractSqlAccessor), or should the Accessors be extended to support this?
>> This may be a place where I could contribute (I've been looking to get
>> involved somehow), if you like I could write a Jira and work on it.
>> 
>> Thanks,
>> Matt
>> 
>> 
>> 

Reply via email to