Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue 43246: Lineage query NPE while processing an UploadedFile #2325

Merged
merged 5 commits into from
Jun 8, 2021

Conversation

labkey-kevink
Copy link
Contributor

Prior to fixing Issue 41675, it was possible that a UploadedFile exp.data
imported into an assay could create a new exp.data and exp.object with
a different LSID and leave the old exp.object in the edge table. The exp.edge
table and the run ended up out of sync.

This PR finds all orphaned UploadedFile exp.object that are outputs of a run,
rebuilds the runs, and removes the orphaned exp.object rows.

Related Issues:

  • Issue 41675: exp.object deleted when detaching exp.data from run
  • Issue 41675: allow updating the LSID of an existing exp.data

Related Pull Requests:

Changes:

  • upgrade script to remove orphaned UploadedFile exp.objects and rebuild edge table
  • add experiment-verifyRunEdges.api utility action

Prior to fixing Issue 41675, it was possible that a UploadedFile exp.data
imported into an assay could create a new exp.data and exp.object with
a different LSID and leave the old exp.object in the edge table.  The exp.edge
table and the run ended up out of sync.

This PR finds all orphaned UploadedFile exp.object that are outputs of a run,
rebuilds the runs, and removes the orphaned exp.object rows.

Related Issues:
- Issue 41675: exp.object deleted when detaching exp.data from run
- Issue 41675: allow updating the LSID of an existing exp.data

Related Pull Requests:
- #1741
- #1758

Changes:
- upgrade script to remove orphaned UploadedFile exp.objects and rebuild edge table
- add experiment-verifyRunEdges.api utility action
Copy link
Contributor

@labkey-jeckels labkey-jeckels left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look OK, but these kinds of upgrade scripts are fragile when the underlying schema changes and the Java code is updated to the new variant, but the code runs before the schema has been completely migrated.

Given the potentially slow run time, what do you think about moving this to a pipeline job that's queued by the upgrade? The server should be useable while it's running, correct?

@labkey-kevink labkey-kevink merged commit 12d241f into develop Jun 8, 2021
@labkey-kevink labkey-kevink deleted the fb_delete_orphaned_objects_43246 branch June 8, 2021 00:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants