I’m trying to wrap my head around bulk_update but am struggling to understand this in the docs:
>>> objs = [
... Entry.objects.create(headline='Entry 1'),
... Entry.objects.create(headline='Entry 2'),
>>> objs.headline = 'This is entry 1'
>>> objs.headline = 'This is entry 2'
>>> Entry.objects.bulk_update(objs, ['headline'])
Why are they using create() instead of update() in the list?
Because the example is trying to demonstrate how
The purpose of the
Entry.objects.create is to create the initial entries in the database to allow
bulk_update to function.
So if I know the object already exists I would replace create() with get()?
If you’re updating a set of items from a queryset, you’re probably better off using the
If you already have a set of items loaded from a previous queryset and are doing other work with them, then
bulk_update may be appropriate.
I’ve got this working code and I’m trying to re-write it using bulk_create and bulk_update to boost performance (update is most important so I’m focusing on that first). This part of my code isn’t really too slow because there are only 50 players but I do need to address the subsequent import which involves importing 100+ characters for each player, which is very slow using the “traditional” way. So I want to understand this using this simpler case.
for player in roster:
new_player = player['id']
existing_player = Player.objects.get(playerId=new_player)
new_player = Player(
print('New player saved')
If nothing else, you’re performing twice as many queries as necessary in your code when the player exists:
Also, it may be worse than that depending upon what’s generating this
But yes, there may be some efficiencies to be gained by aggregating these new and modified
Player objects in lists and using the
bulk functions to batch those operations. In addition to reviewing the use of the
bulk_ functions, make sure you read about the caveats as well.
Yeah I had noticed that but thanks for pointing it out. And “roster” is from an api call and is a json object.
Just wanted to close out this thread:
In the end I realized that what I was doing was wrong. Since this model represents the state of the api at the time of import and is never modified in the app it seemed more logical to delete all and then just create instead of updating since updating would implicate touching every record anyway.
I really appreciate your input Ken.