Possible feature request for verbose delete method

[acomrie]

Wondering if we should consider whether we want to build in any extra controls to help all of us avoid accidental deletion. I am not exactly sure what this would look like, given that a new delete method would need to be implemented on each class, but maybe we could discuss ideas about what might help most.

Currently before deletion a user can see the number of entries being deleted for each table name, and must respond yes to an interactive prompt to enable deletion. Some examples of additions to this could be printing out unique nwb file names, unique lab team names, perhaps some additional sort of user prompt, or requirement to pass a restriction - curious if anyone has other ideas!

Another approach could be to print out very clearly a more verbose/explicit statement on what exactly has been deleted after the deletion has occurred. This could help a user realize that a deletion was unintended at the time of the deletion, so that backup tables could be reinstated quickly. (This could help guard against the case where a deletion only caused a few tables to be cleared out and someone had downstream analyses that did use those deleted tables but didn't have a direct dependency on those tables - then there could be some sort of orphaned data accidentally. It seems possible to only realize this a month or something after the unintended deletion, at which point going back to the backed up tables could be less ideal for others. So perhaps even a way to help a user realize the deletion was unintended at the time of deletion could be handy.)

Just brainstorming though - do chime in with thoughts.

[khl02007]

Something like this is already in place for SpikeSorting table - it looks up your name from the datajoint username and checks if you are one of the people included in the lab team for the entry. If not, it doesn't let you delete.

[lfrank]

I suppose the question here is whether we could extend that to all tables by asking if any to be deleted entry has a lab team key and if so, whether permissions should be granted. Thoughts @khl02007 ?

[khl02007]

I think it could be. But tables like MetricParameters has no natural lab team associated with it, so may require a different strategy. My hope is that the cascading nature of delete would call delete on downstream tables and block any disallowed deletes from occurring (which means we don't need to implement this for all tables), but I haven't tested whether dj behaves this way.

[lfrank]

Unfortunately that doesn't seem to be the case (at least when I looked into it some time ago). We could ask DataJoint for something like this as a feature request, though I'm not sure it's possible for them without a lot of work.