DO_NOT_SAVE_LATER after data processing from one field sets related objects

[thocking@…]

The database system that I set up using Django often uses TextField entries for users to paste in tab-delimited data from an excel spreadsheet. Upon saving, this data is processed using a custom save method. During the processing, many-to-one related objects are created/updated based on these new values.

HOWEVER, this system won't work with the default Django admin framework! The values that are specified in the web form for many-to-one related objects will end up overwriting the values that I got in data processing! That is, my custom save method will set the values for the related objects first, but then the Django web admin form will re-set the values of the related objects to whatever was typed in the data entry boxes on the webpage. Essentially I want the flexibility to mass-enter related objects via copy-paste of a table into a TextField, but at the same time be able to edit the related objects using the Django admin interface if mass-enter batch import is unnecessary for particular instances.

TO SOLVE THE PROBLEM, I introduced the DO_NOT_SAVE_LATER attribute of a Model subclass. If the DO_NOT_SAVE_LATER attribute exists, then related objects from the web admin form will NOT be saved using data from the many-to-one related data entry fields on the webpage. If DO_NOT_SAVE_LATER attribute does not exist, then saving objects from the web admin form works as usual. This solves the problem since I can just set the DO_NOT_SAVE_LATER attribute if my mass-data-entry TextField has something in it, otherwise just save as usual.

Furthermore, you can implement this new feature with this simple patch to django/db/models/manipulators.py:

142c142
< if child_follow:
---

if child_follow and not ('DO_NOT_SAVE_LATER' in dir(new_object)):

[thocking@…]

Patch for django/db/models/manipulators.py

[James Bennett]

Closing in favor of #5390, because that one would offer a clean solution to this problem.