[SYNPY-1760] Add ability to link Grid to CurationTask#1383
Conversation
| "taskProperties was not found in the Synapse response for this CurationTask. " | ||
| "This means it is likely an older CurationTask from before taskProperties was added. " | ||
| "It is recommended that this task be deleted: task.delete(delete_source=False)" |
There was a problem hiding this comment.
Add to the message to recreate the task with the existing source entity
| await self.set_active_grid_session_async( | ||
| active_session_id=grid.session_id, synapse_client=synapse_client | ||
| ) | ||
| except Exception: |
There was a problem hiding this comment.
This should probably be the one that catches the 412 error. Should we have a "finally" clause to delete the grid sesison for all other errors on this active grid session command?
| try: | ||
| await self.set_active_grid_session_async( | ||
| active_session_id=grid.session_id, synapse_client=synapse_client | ||
| ) | ||
| except Exception: | ||
| try: | ||
| await grid.delete_async(synapse_client=synapse_client) | ||
| except Exception: | ||
| Synapse.get_client(synapse_client=synapse_client).logger.warning( | ||
| "Failed to delete orphan grid session %s after status " | ||
| "update failure; manual cleanup may be required.", | ||
| grid.session_id, | ||
| ) | ||
| raise |
There was a problem hiding this comment.
Add a comment
- There can only be one grid session that is active, but there can be multiple grid sessions. So multiple users running this command may run into the 412 error.
There was a problem hiding this comment.
🔥 LGTM! just some minor comments, and will defer to @BryanFauble for a final pass next sprint for the code and @cconrad8 on the documentation.
|
|
||
| ### Step 5: Upsert your edits back into the grid | ||
|
|
||
| `import_csv` upserts rows into the grid based on the `upsert_keys` the administrator configured on the curation task. Existing rows matching on those keys are updated; new rows are inserted. |
There was a problem hiding this comment.
I think the task has the upsert key as a property?
|
|
||
|
|
||
| @dataclass | ||
| class TaskExecutionDetails(ABC): |
There was a problem hiding this comment.
Although Synapse is representing this with inheritance and a base class, we do not have to follow this pattern exactly. In fact this would be the first usage of an abstract base class in the python code. Ideally - If possible I would rather this not exist.
There was a problem hiding this comment.
If there is a case to be said that there are going to be many more of these, then that would be a reason to keep this. If this is all we will have, then I do not think we need to have this extra layer.
There was a problem hiding this comment.
John has mentioned that they plan on having more of these, but I don't have any firm timeline. I'm happy to keep or change this.
| ) | ||
| grid = Grid( | ||
| initial_query=Query( | ||
| sql=f"SELECT * FROM {self.task_properties.file_view_id}" |
There was a problem hiding this comment.
Are there cases where this should be user controlled to set the query to something like, like SELECT col_1, col_2, col_3 ...?
There was a problem hiding this comment.
From a product perspective, this is not supported within the UI flow when people "Open Curator" from a task. opening curator from a task will always select * on the underlying source id (recordset and/or fileview)
| await self.set_active_grid_session_async( | ||
| active_session_id=grid.session_id, synapse_client=synapse_client | ||
| ) | ||
| except Exception: |
There was a problem hiding this comment.
Exception is way too wide to catch here for this logic. You need to catch for the specific exception (I assume an HTTP type exception), and inspect the message for the specific one that you care about. That should be the only case where you clean this up automatically.
There was a problem hiding this comment.
Wouldn't we want to clean up this grid everytime Synapse was unable to set it as the active grid on the CurationTask?
There was a problem hiding this comment.
does it make any sense for the Grid created during this process to stay under any circumstances? If no, then keep as is. If yes, change the behavior.
There was a problem hiding this comment.
I don't think so. In my opinion, the user would be trying to create a grid and attach it with one method. If the attachment didn't work, they would probably try to call this method again, which would leave the grid from the first try.
BryanFauble
left a comment
There was a problem hiding this comment.
Thanks for the changes.
Approving, however please look to at least address #1383 (comment) before merge.
Problem:
Solution:
Added these methods to
CurationTask:get_statusupdate_statusset_active_grid_sessionset_task_state_asynccreate_grid_session_asyncAdded
owner_principal_idtoGridSeparated Curator docs into one for data managers and one for contributors
Testing:
All new methods have unit and integration tests