This would be useful. I had to make physical formats more explicit in the recent remote JDBC driver work (see e.g. Meta.CursorFactory.style), so it’s worth looking at that.
Julian On Dec 15, 2014, at 12:28 PM, Vladimir Sitnikov <[email protected]> wrote: > Hi, > > Current implementation of EnumerableRelImplementor has some assumption > on the physical representation of the data. > > The most "surprising" is that a row with single Integer field should > be represented as Enumerable<Integer>, while a row with two fields > should be Enumberable<Object[]>. > > While this is a performance optimization, it bites you unexpectedly. > > The second problem is you cannot force a particular physical format. > It is a must when calling "external procedure". > For instance, when calling a procedure with cursor() argument, there > must be some predefined calling convention. You can't call > user-defined java function with Enumerable<CustomClass> if it expects > Enumerable<Object[]>. > > I am planning to update EnumerableRelImplementor so it will be > possible to implement Enumerable<Object[]> even for single column > stuff and it will be possible to call UDF with cursor parameters with > desired physical type. > > Any comments/ideas are welcome. > > -- > Regards, > Vladimir Sitnikov
