On 2021-12-08 10:13, Dmitry Yemanov wrote:
28.11.2021 14:45, Mark Rotteveel wrote:
We don't have anything like this. Theoretically, we could extend
IRecordSet with something similar (although it would also require a
protocol change), but the question is whether it's really needed.
Personally, I don't see it useful per se. If users want to know a
number of rows, then perhaps an explicit getRowCount() method would
be more useful (*). But AFAIU the Java API does not mention it.
(*) not applicable to uni-directional cursors?
The intent of the method is to report the position of the current row.
The example it is abused by some to get the total size was just an
illustration of why people would expect a value after requesting the
last row. But the same would be a problem if people went to last,
scrolled around and then want to know the current row position.
I was thinking about providing both "current position" and "row count"
information values for a cursor. Both are doable, however the former
has some issues:
1) Adjustments due to prefetch should be taken into account at both
client and server sides, thus complicating the code (information
response buffer must be parsed, value received from the engine/server
must be replaced with the adjusted one).
2) If used "with purpose", it may be requested by the client after
every fetch, thus multiplying the round-trips and killing the prefetch
benefits. So it could make sense to request the position (send
op_info_cursor) internally after every op_fetch_scroll packet. As
every fetch request may return multiple rows, sending many positions
is unnecessary and only position of the first row could be returned.
This puts additional requirements to the client-side protocol
implementations.
3) "row count" makes it possible to know the position after
fetchLast() and everything else could be calculated locally by the
client library, thus making the server-supported "current position"
totally unnecessary.
Do I miss anything? Could we agree on having only "row count" returned
via op_info_cursor and leaving "cursor position" (getRow() in Java
API) up the connectivity library developers?
That sounds doable, but I won't have time to really look and think about
this until the weekend. I'll reply then if I have more concerns.
Mark
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
