You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation relies on the database errors to specify if something can not be (un)linked to a study. This is useful because there is less overhead in the happy-path. However, when some entities don't exist, or are already attached (for attach) or are not attached (for detach), then only the first such conflict is provided by the database error. This means that a user that tries to attach multiple entities at once, with multiple conflicts at once, can only resolve the conflicts one-by-one (or they have to collect the study/tasks/runs themselves, then do the matching). It would be good to do this check serverside only if we already establish there is already at least one conflict.
The text was updated successfully, but these errors were encountered:
The current implementation relies on the database errors to specify if something can not be (un)linked to a study. This is useful because there is less overhead in the happy-path. However, when some entities don't exist, or are already attached (for attach) or are not attached (for detach), then only the first such conflict is provided by the database error. This means that a user that tries to attach multiple entities at once, with multiple conflicts at once, can only resolve the conflicts one-by-one (or they have to collect the study/tasks/runs themselves, then do the matching). It would be good to do this check serverside only if we already establish there is already at least one conflict.
The text was updated successfully, but these errors were encountered: