You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Xavier Leong <le...@persistent.com> on 2015/03/25 10:33:56 UTC
[CALCITE-523] Implementing fetch for Avatica
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.
Re: [CALCITE-523] Implementing fetch for Avatica
Posted by Julian Hyde <ju...@gmail.com>.
+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 <nd...@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 <le...@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.
>>
>>
Re: [CALCITE-523] Implementing fetch for Avatica
Posted by Nick Dimiduk <nd...@gmail.com>.
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 <le...@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.
>
>