calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <julianh...@gmail.com>
Subject Re: [CALCITE-523] Implementing fetch for Avatica
Date Wed, 25 Mar 2015 16:48:39 GMT
+1 what Nick says

I don't think JdbcMeta implements row limit yet, but it should.

Julian


> On Mar 25, 2015, at 9:33 AM, Nick Dimiduk <ndimiduk@gmail.com> wrote:
> 
> Hi Xavier,
> 
> Please have a look at my avatica branch [0]. The commit for CALCITE-636 [1]
> does some re-plumbing in this area. My focus has been on the new JdbcMeta,
> which does not extend MetaImpl, so the changes may not be available to you.
> Let me know if you think some refactoring could allow for more code reuse
> in this area.
> 
> -n
> 
> [0]: https://github.com/ndimiduk/incubator-calcite/tree/avatica-to-prod
> [1]:
> https://github.com/ndimiduk/incubator-calcite/commit/b40477ac47136e9b0dece06e74222591db7e4321#diff-e7ec7997f2bd520159b34d6952106607
> 
> On Wed, Mar 25, 2015 at 2:33 AM, Xavier Leong <leongxfh@persistent.com>
> wrote:
> 
>> Hi, with recent fix from [CALCITE-618] including a fetch request to target
>> fetching result set with limited row, looks like it's related to
>> [CALCITE-523]. We are trying to get Avatica to work on prepareStatement,
>> missing piece of the implementation is the meta.execute request which runs
>> after the meta.prepare request when the prepareStatement is created from
>> the connection.
>> 
>> I guess it will be good to get the fetch to work as well after the
>> meta.execute request return with the limit maxRowCount, so that moving the
>> cursor beyond the limit will trigger a meta.fetch, which will be handle  by
>> AvaticaServer returning the next maxRowCount. Reading from 523, it mention
>> about limit byte size as well, but I think for this case, it should only on
>> the row count limit, agree?
>> 
>> The resultSet also only support 1 direction right now, which is sufficient
>> for our case.
>> 
>> On another issue, related to AvaticaStatement execute(sql), it seems like
>> it is taking another path from executeQuery(sql), and it does not work for
>> remote interface, we are making it so that it call executeQuery(sql), do
>> you foresee any problems with doing so?
>> 
>> Thanks.
>> 
>> 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.
>> 
>> 


Mime
View raw message