Anything <=0 should be treated as "all results" (at least given what I
recall from the code comments). Would be good to verify regardless. It's
entirely possible that when I introduced the new attribute, I
(unnecessarily) changed the previous semantics :)
F21 wrote:
I tried setting it to -1 and it appears to return unlimited rows. Maybe
this is not a bug, but just needs to be better documented?
On 22/08/2016 11:59 AM, Josh Elser wrote:
Hrm, that sounds like a bug. The default value of '0' and an explicit
value of '0' should have the exact same semantics (an unlimited number
of values for the statement).
Mind filing a bug?
F21 wrote:
Hi Josh,
Thanks! That clears things up. I noticed that if I explicitly set
max_rows_total to 0, it returns 0 rows, which is different from omitting
max_rows_total.
Is this the expected behavior? Is it possible to set max_rows_total and
have it behave like the default (return all rows without any limit)?
Cheers,
Francis
On 20/08/2016 12:35 AM, Josh Elser wrote:
Hi Francis,
I tried to do explicit testing here to make sure that the 1.7 to 1.8
upgrade should be painless for you. In places where the protocol has
changed, the old attributes and functionality remains (we explicitly
check for the old value and the absence of the new value).
max_rows_total defaults to 0 which is directly set on the JDBC
Statement object. The value of 0 is special in that it means there is
no limit on the number of results returned by that Statement (this
query).
F21 wrote:
Hey guys,
I am in the process of upgrading the go (golang) avatica driver to
support Calcite/Avatica 1.8.0.
I noticed that the protobuf definitions deprecated max_row_count in
favor of max_rows_total.
I also noticed that if I do not include max_rows_total in a Prepare or
PrepareAndExecute request, the server will still accept the request.
In the event that max_rows_total is not provided, what is the default
value/behavior assigned by the server?
Cheers,
Francis
