detach_object_resources now works for deferred objects #974
Conversation
| assert ContentObject.objects.filter( | ||
| object_id=party.id, resource=resource).exists() | ||
|
|
||
| party_deferred = Party.objects.all().defer('attributes')[0] |
There was a problem hiding this comment.
Just a little hint about one of the quirks of Django: In this case, it's better to write Party.objects.defer('attributes').first(). When you call Party.objects.all() the ORM gets all Party records from the database, even though you only want the first one. So when you have a huge table, your query wastes resources because the database needs to compile the records and send them across the network, which takes longer the bigger your dataset is. Party.objects.defer('attributes').first() gets only one record instead. (Nothing you need to change now because it doesn't make a big difference in this case, but something to keep in mind when constructing queries.)
There was a problem hiding this comment.
I did not know that, that's really good to know. Thanks!
| party_deferred.delete() | ||
| assert not ContentObject.objects.filter( | ||
| object_id=party.id, resource=resource).exists() | ||
| assert Party.objects.all().count() == 0 |
There was a problem hiding this comment.
Similar to the above: If you want to check whether there is a record or not, it's better to use Party.objects.exists() because that just checks if it can find one record in the table, whereas Party.objects.all().count() has to find all the records first to count them.
There was a problem hiding this comment.
Also did not know you could use exists when you weren't trying to get a specific record. Neat!
amplifi
force-pushed
the
bug/#803-detach-resources
branch
from
7d0fcc7 to
d3d1859
Compare
Proposed changes in this pull request
detach_object_resourcesnow works for deferred objectsWhen should this PR be merged
Whenever, unless this is a big enough bug that it needs to be added before releasing to platform.
Risks
None
Follow up actions
None