Getting Meta.CalciteSignature from Meta.Signature

[Yeong Wei Lai <la...@persistent.com>]

Hi All,

I am currently implementing the preparedStatements for Remote JDBC.

During a Client's connection.preparedStatement( ... ) which invokes the CalciteMetaImpl.prepare that creates a Meta.CalciteSignature but return as Meta.Signature type.

Upon Client's preparedStatement.executeQuery(), I am translating the invocation into a call for CalciteMetaImpl.execute(StatementHandle h, Signature signature) (my new implementation) that should be able to return a MetaResultSet which eventually be processed by the LocalService.toResponse.

However in the following call for meta.createIterable, there is an attempt to cast the Meta.Signature into Meta.CalciteSignature which currently throws the cast type exception.

Is there a way that I can create the Meta.CalciteSignature Object from a Meta.Signature Object ?

Thanks!

Rgds,
Yeong

DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.

Re: Getting Meta.CalciteSignature from Meta.Signature

[Julian Hyde <ju...@gmail.com>]

Are you aware that Nick and I have been doing some work in this area? We recently implemented prepare, bind, fetch. See my https://github.com/julianhyde/incubator-calcite/tree/calcite-618 branch. I suggest that you do your work based on that branch, otherwise we are going to repeat each other's work.

I don't remember exactly why I introduced CalciteSignature. It seems OK to use it locally (i.e. the in-process Calcite driver speaking to CalciteMetaImpl) but it seems wrong to use it remotely. If you are connecting to Calcite via the remote JDBC I hope it is possible to just use Avatica's remote driver and Avatica's protocol, and not have anything Calcite specific on the client or in the protocol. So, that CalciteSignature should be serialized to JSON just the same as a Meta.Signature.

If the purported advantages of CalciteSignature, "It gives the Avatica driver framework the information it needs to create a prepared statement, or to execute a statement directly, without an explicit prepare step", still hold then we should figure out how to add those to the Avatica protocol.

Julian


> On Mar 20, 2015, at 4:26 AM, Yeong Wei Lai <la...@persistent.com> wrote:
> 
> Hi All,
> 
> I am currently implementing the preparedStatements for Remote JDBC.
> 
> During a Client's connection.preparedStatement( ... ) which invokes the CalciteMetaImpl.prepare that creates a Meta.CalciteSignature but return as Meta.Signature type.
> 
> Upon Client's preparedStatement.executeQuery(), I am translating the invocation into a call for CalciteMetaImpl.execute(StatementHandle h, Signature signature) (my new implementation) that should be able to return a MetaResultSet which eventually be processed by the LocalService.toResponse.
> 
> However in the following call for meta.createIterable, there is an attempt to cast the Meta.Signature into Meta.CalciteSignature which currently throws the cast type exception.
> 
> Is there a way that I can create the Meta.CalciteSignature Object from a Meta.Signature Object ?
> 
> Thanks!
> 
> Rgds,
> Yeong
> 
> DISCLAIMER
> ==========
> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.
>