On 2023-07-14 17:02, Dave Cramer wrote:
> The fly in the ointment here is when they setFetchSize and we decide to
> use a Portal under the covers.
A person might language-lawyer about whether setFetchSize even applies
to the kind of thing done with executeUpdate.
Hmm ... the apidoc for setFetchSize says "Gives the JDBC driver a hint
as to the number of rows that should be fetched from the database when
more rows are needed for ResultSet objects generated by this Statement."
So ... it appears to apply to any "ResultSet objects generated by this
Statement", and getGeneratedKeys returns a ResultSet, so maybe
setFetchSize should apply to it.
OTOH, setFetchSize has @since 1.2, and getGeneratedKeys @since 1.4.
At the time setFetchSize was born, the only way you could get a
ResultSet
was from the kind of thing you'd use executeQuery for.
So when getGeneratedKeys was later added, a way of getting a ResultSet
after an executeUpdate, did they consciously intend it to come under
the jurisdiction of existing apidoc that concerned the fetch size of
a ResultSet you wanted from executeQuery?
Full employment for language lawyers.
Moreover, the apidoc does say the fetch size is "a hint", and also that
it applies "when more rows are needed" from the ResultSet.
So it's technically not a misbehavior to disregard the hint, and you're
not even disregarding the hint if you fetch all the rows at once,
because
then more rows can't be needed. :)
Regards,
-Chap