Parallel edits cause multiple draft versions

[qqmyers]

In working with datasets with 100+ files, we've seen an issue that is probably related to #2132 and #2545 :
if a user(s) working on the same dataset try a save for an edit to a file or the dataset before a prior save has finished, you end up with multiple draft versions, each with some of the changes. (It's a little confusing because you can only see the latest draft version in the web interface). The prior changes to grey out/remove the add/edit metadata, publish, etc. buttons helps but doesn't address the case where multiple windows were open or when multiple users/browser are in play.

To handle the underlying cause, we've gone ahead to implement an editInProgress lock that will a) warn users that the dataset can't be edited temporarily, and b) stop any attempts from other pages/browsers that would otherwise corrupt the database. (This is somewhat analogous to the Dcm lock...).

Also - FWIW: in trying to recover from an instance of this with 4 draft versions, I was able to delete a datasetversion manually (essentially recursing to delete entries in every table that referenced the version or entities associated with the version) and by using the delete draft button in the gui. I don't know when #5542 was introduced, but I think that the same issue that stopped you from deleting one draft version when starting from a published version view would have affected deleting in the multiple draft case. My guess is that, if anyone has this problem in a prior version, deleting form the draft page and/or updating to get the #5542 fix would allow removal of the extra drafts without having to touch the DB.

[scolapasta]

@qqmyers I'm a little surprised by this because I thought we had added a constraint to make sure that multiple drafts couldn't be created - in the issue you referenced #2132. Is that not the case?

Doing the locking here may be cleaner and still worthwhile, but first would like to understand a little about why this issue is occurring and previous attempted fix not working.

[qqmyers]

@scolapasta - the fix in #2132 is at the GUI/view-level. If your action in one tab starts a long-running edit, if you try to get back to an edit form, your buttons will disabled. However, if you have multiple tabs/people/browsers involved in editing, you can still get to and use edit forms. This could potentially be addressed with user education (except for the case of two people editing one dataset), but it's painful enough to clean up that I thought adding a lock to avoid concurrent edits would be better.

[scolapasta]

@qqmyers #2132 specifically references adding the following constraint to the db:

CREATE UNIQUE INDEX one_draft_version_per_dataset ON datasetversion
(dataset_id) WHERE versionstate='DRAFT';

Is that not working to block multiple drafts?

[qqmyers]

@scolapasta - A quick check on our dev db shows that we didn't have this constraint in place. Scanning the releases I see it in the 4.2.1 to 4.2.2 upgrade script with a note "--It may not be applied until all of the datasets with
--multiple drafts have been resolved" I think QDR started after that though, so I'm not sure why we wouldn't have it ( - I don't think we had a pre 4.2.2 db with multiple drafts).

In any case, you're right that this should eliminate the need for a lock. I'll take a look and see if any of the messaging I added is still useful.

[qqmyers]

FWIW: looks like we never ran reference_data.sql - I don't see any of the other db changes/entries from that file in our db...

[qqmyers]

@scolapasta - After some internal discussion, I think QDR is going to keep this lock since it provides users with a useful warning when long edits are in progress (that disappears when the lock is released), versus just failing due to the db constraint from #2132 (which we now have in place). (FWIW: I don't see a way to provide a warning with just the db constraint in place.)
I think the primary use case is with curators wanting to make multiple changes to datasets with many files, which may be rare enough to not be worth merging this code into DV. If not, you can close this and we'll just maintain it in our fork.