Changes between Version 1 and Version 2 of Ticket #33191


Ignore:
Timestamp:
Oct 13, 2021, 3:11:28 AM (3 years ago)
Author:
Carlton Gibson
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #33191 – Description

    v1 v2  
    1313In the application where this behavior was first observed, the application was creating thousands of parent and child objects using bulk_create().  The subsequent lazy reads occurred when creating log entries to record the action, and added thousands of unwanted SELECT queries.
    1414
    15 Closed ticket 29497 solved a problem with potential data loss in this situation by essentially executing {{{child.parent_id = child.parent.pk}}} while preparing the child object to be saved.  However, when the child's ForeignKeyDeferredAttrbute "parent_id" changes value from None to the parent's ID, the child's internal cache containing the reference to "parent" is cleared.  The subsequent reference to child.parent then must do a lazy read and reload parent from the database.
     15Closed ticket #29497 solved a problem with potential data loss in this situation by essentially executing {{{child.parent_id = child.parent.pk}}} while preparing the child object to be saved.  However, when the child's ForeignKeyDeferredAttrbute "parent_id" changes value from None to the parent's ID, the child's internal cache containing the reference to "parent" is cleared.  The subsequent reference to child.parent then must do a lazy read and reload parent from the database.
    1616
    1717A workaround to avoid this lazy read is to explicitly update both the "parent_id" and "parent" cache entry by adding this non-intuitive statement:
Back to Top