Changes between Version 1 and Version 4 of Ticket #35918
- Timestamp:
- Nov 20, 2024, 5:40:53 PM (4 weeks ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #35918
- Property Has patch set
- Property Triage Stage Unreviewed → Accepted
-
Ticket #35918 – Description
v1 v4 1 1 (This refactor is motivated by an ongoing experiment to integrate async cursor work into the ORM, by simplifying some cursor management) 2 2 3 In `django. cdb.models.sql.compiler.Compiler.execute_sql`, we can pass in the following result types: `SINGLE`, `MULTI`, `NO_RESULTS`, and `CURSOR`.3 In `django.db.models.sql.compiler.Compiler.execute_sql`, we can pass in the following result types: `SINGLE`, `MULTI`, `NO_RESULTS`, and `CURSOR`. 4 4 5 5 `execute_sql`'s docstring to that effect does not reflect this. … … 13 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. 14 14 15 To simplify cursor resource management, I have a two-pronged proposal:15 To simplify cursor resource management, I have a ~~two~~ one-pronged proposal: 16 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 17 ~~- `CURSOR` is renamed to `LEAK_CURSOR`, as a way to more strongly indicate that you are now in charge of the cursor~~ 18 18 19 19 Main point here is to reduce the number of places an open cursor might come into play.