Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors
27.11.2021 17:28, Mark Rotteveel wrote: I'm running into some odd behaviour. As soon as I do a fetch_next or fetch_prior, any subsequent fetch ignores the fetch direction, and applies fetch_next (or fetch_prior). Correction: it behaves as fetch_next (or fetch_prior) for the amount of rows that was fetched in the last fetch (or at least some number of rows buffered on the server). I can understand needing to take into account the client-side buffer, but I don't think that I should take into account any rows that the server has buffered. If you requested N rows from the server but now switching to the different fetch operation before getting all those rows, I expect the client to receive (and discard) the remaining part of the requested rows before sending the new opcode. This is what fbclient does currently. However, I can see the point in letting the server to cleanup the queue instead of the client. I will give it a try. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors
On 27-11-2021 14:10, Mark Rotteveel wrote: On 26-11-2021 10:10, Dmitry Yemanov wrote: I'd appreciate if Mark could test scrollability from the Jaybird side too (i.e. without fbclient involved), but the new protocol should be supported for that. I'm running into some odd behaviour. As soon as I do a fetch_next or fetch_prior, any subsequent fetch ignores the fetch direction, and applies fetch_next (or fetch_prior). Correction: it behaves as fetch_next (or fetch_prior) for the amount of rows that was fetched in the last fetch (or at least some number of rows buffered on the server). I can understand needing to take into account the client-side buffer, but I don't think that I should take into account any rows that the server has buffered. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors
On 26-11-2021 10:10, Dmitry Yemanov wrote: I'd appreciate if Mark could test scrollability from the Jaybird side too (i.e. without fbclient involved), but the new protocol should be supported for that. I'm running into some odd behaviour. As soon as I do a fetch_next or fetch_prior, any subsequent fetch ignores the fetch direction, and applies fetch_next (or fetch_prior). Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors
Dmitry Yemanov wrote 27.11.2021 12:23: I would consider adding a NO_BATCH flag (which is currently triggered using FOR UPDATE syntax) to cursorFlags. That would be useful in some cases. And if statements with "WHERE CURRENT OF" condition also were somehow marked client libraries could force cursor position synchronization before executing them. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors
27.11.2021 12:42, Mark Rotteveel wrote: Yes, I think that is perfectly acceptable for an initial version. Scrollable cursors are a bit of an oddity anyway, but having scrollable cursors in embedded access, but not in remote access is IMHO less acceptable than bad performance. As long as the performance behaviour is clearly documented, people can make the decision if the bad performance is worth the utility of scrollable cursors for themselves. I've just committed network support for scrollable cursors to master. Prefetch logic is supported for NEXT/PRIOR navigations. Protocol changes are documented here: https://github.com/FirebirdSQL/firebird/issues/7051 Are other values than 0 or 1 (CURSOR_TYPE_SCROLLABLE) currently possible for cursorFlags (flags)? Nope (so far). Although remembering our old discussion re. whether scrollability should be represented via a syntax keyword or an API flag, I would consider adding a NO_BATCH flag (which is currently triggered using FOR UPDATE syntax) to cursorFlags. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Firebird and DSQL Scrollable Cursors
On 26-11-2021 10:10, Dmitry Yemanov wrote: Mark et al, Yes, I think that is perfectly acceptable for an initial version. Scrollable cursors are a bit of an oddity anyway, but having scrollable cursors in embedded access, but not in remote access is IMHO less acceptable than bad performance. As long as the performance behaviour is clearly documented, people can make the decision if the bad performance is worth the utility of scrollable cursors for themselves. I've just committed network support for scrollable cursors to master. Prefetch logic is supported for NEXT/PRIOR navigations. Protocol changes are documented here: https://github.com/FirebirdSQL/firebird/issues/7051 Are other values than 0 or 1 (CURSOR_TYPE_SCROLLABLE) currently possible for cursorFlags (flags)? Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
