Changes between Initial Version and Version 1 of Ticket #35918


Ignore:
Timestamp:
Nov 18, 2024, 11:06:02 PM (5 days ago)
Author:
Raphael Gaschignard
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #35918 – Description

    initial v1  
    11(This refactor is motivated by an ongoing experiment to integrate async cursor work into the ORM, by simplifying some cursor management)
    22
    3 In ``django.cdb.models.sql.compiler.Compiler.execute_sql``, we can pass in the following result types: ``SINGLE``, ``MULTI``,  ``NO_RESULTS``, and ``CURSOR``.
     3In `django.cdb.models.sql.compiler.Compiler.execute_sql`, we can pass in the following result types: `SINGLE`, `MULTI`,  `NO_RESULTS`, and `CURSOR`.
    44
    5 ``execute_sql``'s docstring to that effect does not reflect this.
     5`execute_sql`'s docstring to that effect does not reflect this.
    66
    7 - ``SINGLE`` returns a single row. It closes the cursor it uses to query.
    8 - ``MULTI`` returns many rows (wrapped in a cursor iterator). This either closes the cursor it uses to query, or returns an iterator that takes ownership of the cursor to close the cursor once reading of all the results are done.
    9 - ``NO_RESULTS`` returns nothing. It closes the cursor it uses to query.
    10 - ``CURSOR`` returns the cursor, without closing the cursor, effectively making the caller in charge of closing the cursor
     7- `SINGLE` returns a single row. It closes the cursor it uses to query.
     8- `MULTI` returns many rows (wrapped in a cursor iterator). This either closes the cursor it uses to query, or returns an iterator that takes ownership of the cursor to close the cursor once reading of all the results are done.
     9- `NO_RESULTS` returns nothing. It closes the cursor it uses to query.
     10- `CURSOR` returns the cursor, without closing the cursor, effectively making the caller in charge of closing the cursor
    1111
    1212
    13 ``CURSOR`` returns an unclosed cursor that has to be manage by the caller. In practice, though, apart from a single test usage, Django's codebase currently only uses ``CURSOR`` to do one thing: get the number of rows, then close the cursor.
     13`CURSOR` returns an unclosed cursor that has to be manage by the caller. In practice, though, apart from a single test usage, Django's codebase currently only uses `CURSOR` to do one thing: get the number of rows, then close the cursor.
    1414
    1515To simplify cursor resource management, I have a two-pronged proposal:
    16 - a new result type, ``ROW_COUNT``, returns the rows and closes the cursor for you. This covers all non-test usage of ``CURSOR`` in Django currently.
    17 - ``CURSOR`` is renamed to ``LEAK_CURSOR``, as a way to more strongly indicate that you are now in charge of the cursor
     16- a new result type, `ROW_COUNT`, returns the rows and closes the cursor for you. This covers all non-test usage of `CURSOR` in Django currently.
     17- `CURSOR` is renamed to `LEAK_CURSOR`, as a way to more strongly indicate that you are now in charge of the cursor
    1818
    1919Main point here is to reduce the number of places an open cursor might come into play.
Back to Top