calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <>
Subject Re: Starting a transaction with avatica and a few other things
Date Mon, 04 Apr 2016 22:54:23 GMT
Oh, cool. Didn't realize that was you :). Much appreciated.

I'm not sure I understand your question. A Frame is a collection of rows 
(in the context of a SELECT, anyways). In the traditional JDBC sense, a 
ResultSet is backed by many Frames.

The common case is the following. Given some batch (frame) size of 100 
entries, you would see the following for a query returning 250 entries:

PrepareAndExecute(maxRowCount=100) => Frame[0-100, done=false],
Fetch(offset=100, maxRowCount=100) => Frame[100-200, done=false],
Fetch(offset=200, maxRowCount=100) => Frame[200-250, done=true].

Does that make sense?

F21 wrote:
> Ah, makes sense. Also,should the offset be incremented on a per frame or
> a per row basis? Regarding the offsets being 0, I opened CALCITE-1181,
> so hopefully we can get that sorted.
> On 4/04/2016 11:57 PM, Josh Elser wrote:
>> Hrm, I'm not sure off the top of my head how the offset returned by
>> the server operates. If it's not returning the offset for the current
>> "batch" of results, that's an accidental omission (but a client can
>> easily track the offset, which would explain how the omission happened
>> in the first place).
>> F21 wrote:
>>> Hey Josh,
>>> Thanks for your examples, those are pretty useful. I have one question
>>> about offsets. In your example, you started with an offset of 0 and
>>> added to the offset as you fetched more rows from the server. Does the
>>> first frame from a prepareAndExecute result always have an offset of 0?
>>> From my limited testing, it appears the offsets returned by the server
>>> never increases.
>>> Thanks!
>>> On 29/03/2016 1:43 AM, Josh Elser wrote:
>>>> If you're still trying to wrap your head around how to interact with
>>>> the Avatica server (PQS in your case),
>>>> might be of some
>>>> help.
>>>> Specifically, I tried to outline what kind of requests you might send
>>>> for some basic operations
>>>> LMK if these are helpful (or not) and what kind of additional
>>>> documentation/instructions would be useful.
>>>> James Taylor wrote:
>>>>> That documentation is still the same. Going through the query server
>>>>> doesn't change anything. The important quote there about starting a
>>>>> transaction:
>>>>> A transaction is started implicitly through the execution of a
>>>>> statement on
>>>>> a transactional table and then finished through either a commit or
>>>>> rollback.
>>>>> On Sat, Mar 26, 2016 at 11:08 PM, F21<> wrote:
>>>>>> Hi James,
>>>>>> Thanks for the quick reply. The docs does talk about how to use
>>>>>> transactions with phoenix, but doesn't seem to answer my questions
>>>>>> regarding implementing transactions for a phoenix query server
>>>>>> client.
>>>>>> Cheers!
>>>>>> On 27/03/2016 5:04 PM, James Taylor wrote:
>>>>>>> Please read and
let us
>>>>>>> know
>>>>>>> if
>>>>>>> it doesn't answer your questions.
>>>>>>> Thanks,
>>>>>>> James
>>>>>>> On Sat, Mar 26, 2016 at 10:00 PM, F21<>
>>>>>>> Hi guys,
>>>>>>>> As I posted on the Phoenix list a few days ago, I am working
on a
>>>>>>>> golang
>>>>>>>> client for the phoenix query service (which uses avatica).
>>>>>>>> In regards to starting a transaction, I see that the protobuf
>>>>>>>> reference
>>>>>>>> contains Commit and Rollback requests, but there isn't any
>>>>>>>> request.
>>>>>>>> Is sending a ConnectionSync request and setting autoCommit
>>>>>>>> false the
>>>>>>>> correct way to start a transaction?
>>>>>>>> Also, what is the state of autoCommit when I send an Open
>>>>>>>> to the
>>>>>>>> server?
>>>>>>>> Finally, the Open request allows me to send a map called
>>>>>>>> What is
>>>>>>>> suppose to go into this map?
>>>>>>>> Cheers!

View raw message