If a computed field cf depends on a local concrete field f that got changed in python, there is one desync state uncovered with update_fields:
None - all good, cf gets calculated and updated in db along with f
['f'] - all good, mro logic kicks in extending update_fields to ['f', 'cf']
['cf'] - only cf was marked for updating, gets calculated with new f value, but the new f value never enters the db --> cf out of sync to f
This needs at least a warning in the docs about that weird update_fields usage.
Another way to deal with that would be to extend updated fields also in the computed --> source field direction. Not sure if thats the wanted behavior, there might be reason, why the user left out f in the first place.
If a computed field
cfdepends on a local concrete fieldfthat got changed in python, there is one desync state uncovered withupdate_fields:None- all good,cfgets calculated and updated in db along withf['f']- all good, mro logic kicks in extending update_fields to['f', 'cf']['cf']- onlycfwas marked for updating, gets calculated with newfvalue, but the newfvalue never enters the db -->cfout of sync tofThis needs at least a warning in the docs about that weird
update_fieldsusage.Another way to deal with that would be to extend updated fields also in the computed --> source field direction. Not sure if thats the wanted behavior, there might be reason, why the user left out
fin the first place.