Story #6134: [EPIC] Pulp import/export
Investigate/decide whether "set last_export to null explicitly before allowing exporter to be deleted" is a Good Idea
From discussion started while writing functional tests :
pulpcore/tests/functional/api/using_plugin/test_pulpexport.py if path.exists(exporter.path): shutil.rmtree(exporter.path) # NOTE: you have to manually undo 'last-export' if you really really REALLY want to # delete an Exporter. This is...probably correct? @daviddavis Hmm. I think deleting the exporter should just cascade delete the exports? @ggainey We protect from deleting the last_export of a PulpExporter (see https://github.com/pulp/pulpcore/blob/master/pulpcore/app/models/exporter.py#L198) - iirc that kept PulpExporter from being deleted if it had ever been exported, unless/until you explicitly set last_export to null first. I will experiment some more tho, a lot happened between when I wrote that comment and now. @daviddavis Ok. I do see value in preventing a user from accidentally deleting an exporter that has exported but unsetting a field to delete an object seems weird. @ggainey You are not wrong. There is probably a better way to do this, will leave this comment open and think about it overnight. @daviddavis Ok sounds good. I'm fine with leaving it this way as long as it's clear to the user that the last_export has to be unset in order to delete.
Decide if this is appropriate. If not, decide what the right thing to do is, and use this issue to get the change checked in.
Updated by ggainey over 3 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to ggainey
@daviddavis - having been bitten by this behavior a number of times now, I think I have convinced myself that 'special protection' for last_export is a) not actually all that useful, and b) very, very inconvenient for the main workflow of deleting an Exporter. With the addition of start_versions= and version=, one can recreate a last-export at will. I think I would like to remove this protection. Objections?