I think I am misunderstanding your comment from PHOENIX-1181.
- If I set maxRowCount to 100, and the query returns 250 entries, I
should get 1 frame containing 100 rows back with the option to fetch
more rows (with the amount of rows subject to the maxRowCount of the
fetch request), right?
- A executeResponse (from a PrepareAndExecuteRequest) can contain
multiple resultSets witch each resultSet containing 1 frame. Under what
circumstances will you get multiple resultSets in an executeResponse?
From my limited testing, I always get 1 resultSet in my executeResponses.
Thanks again! :)
On 5/04/2016 8:54 AM, Josh Elser wrote:
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),
https://issues.apache.org/jira/browse/CALCITE-1081 might be of some
help.
Specifically, I tried to outline what kind of requests you might send
for some basic operations
http://people.apache.org/~elserj/calcite/docs/avatica_example_client.html
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<[email protected]> 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 https://phoenix.apache.org/transactions.html and
let us
know
if
it doesn't answer your questions.
Thanks,
James
On Sat, Mar 26, 2016 at 10:00 PM, F21<[email protected]> wrote:
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 Begin
request.
Is sending a ConnectionSync request and setting autoCommit to
false the
correct way to start a transaction?
Also, what is the state of autoCommit when I send an Open request
to the
server?
Finally, the Open request allows me to send a map called info.
What is
suppose to go into this map?
Cheers!
