Changes between Version 1 and Version 4 of Ticket #35918


Ignore:
Timestamp:
Nov 20, 2024, 5:40:53 PM (4 weeks ago)
Author:
Raphael Gaschignard
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #35918

    • Property Has patch set
    • Property Triage Stage UnreviewedAccepted
  • Ticket #35918 – Description

    v1 v4  
    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.db.models.sql.compiler.Compiler.execute_sql`, we can pass in the following result types: `SINGLE`, `MULTI`,  `NO_RESULTS`, and `CURSOR`.
    44
    55`execute_sql`'s docstring to that effect does not reflect this.
     
    1313`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
    15 To simplify cursor resource management, I have a two-pronged proposal:
     15To simplify cursor resource management, I have a ~~two~~ one-pronged proposal:
    1616- 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
     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