This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author erlendaasland
Recipients berker.peksag, erlendaasland, serhiy.storchaka
Date 2021-08-22.09:06:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1629623190.98.0.383271331638.issue44976@roundup.psfhosted.org>
In-reply-to
Content
Currently, we build the first result row in the _pysqlite_query_execute() loop if sqlite3_step() returned SQLITE_ROW. When the user asks for a row (for example, using sqlite3.Cursor.fetchone()), this pre-built row is returned, and the next row is prepared.

Suggesting to lazily build result rows instead.

Cons:
- no result tuples are built unless sqlite3.Cursor.fetch*() is called
- no need to keep the next result row (tuple) in pysqlite_Cursor; rows are built on demand
- pysqlite_cursor_iternext() is vastly simplified (50% less lines of code)
- the main loop in _pysqlite_query_execute() is further simplified

Cons:
- code churn


git diff main --shortstat: 2 files changed, 29 insertions(+), 58 deletions(-)
History
Date User Action Args
2021-08-22 09:06:31erlendaaslandsetrecipients: + erlendaasland, berker.peksag, serhiy.storchaka
2021-08-22 09:06:30erlendaaslandsetmessageid: <1629623190.98.0.383271331638.issue44976@roundup.psfhosted.org>
2021-08-22 09:06:30erlendaaslandlinkissue44976 messages
2021-08-22 09:06:30erlendaaslandcreate