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
{{ message }}
This repository has been archived by the owner on Jan 18, 2020. It is now read-only.
When a user edits a cohort, the change should be queued for calculation. Cohort calculations ideally should run on a server other than the main web server, but at a minimum should not run immediately to prevent mistakes or rapid edits from clogging things up.
Once a user edits a cohort, the allele frequency computation should be put into a queue. It would be good to do a quick diff to see what has happened to the cohort. If users have only deleted samples, these changes can be immediate, with the new cohort simply being a copy of the old, with the samples in question removed.
Otherwise, the entire cohort should be recomputed. Ideally, it would be good to delay this just slightly, so that people have a chance to edit before the computation starts. We'll have to see how long these take to determine what frequency they should run. Ideally, users wouldn't have to wait too long for them. But we also don't want to have the database churning computing all sorts of cohort frequencies at once. I am also cognizant of not over-complicating this, so if there's a simple solution, I'm game.
The text was updated successfully, but these errors were encountered:
When a user edits a cohort, the change should be queued for calculation. Cohort calculations ideally should run on a server other than the main web server, but at a minimum should not run immediately to prevent mistakes or rapid edits from clogging things up.
Once a user edits a cohort, the allele frequency computation should be put into a queue. It would be good to do a quick diff to see what has happened to the cohort. If users have only deleted samples, these changes can be immediate, with the new cohort simply being a copy of the old, with the samples in question removed.
Otherwise, the entire cohort should be recomputed. Ideally, it would be good to delay this just slightly, so that people have a chance to edit before the computation starts. We'll have to see how long these take to determine what frequency they should run. Ideally, users wouldn't have to wait too long for them. But we also don't want to have the database churning computing all sorts of cohort frequencies at once. I am also cognizant of not over-complicating this, so if there's a simple solution, I'm game.
The text was updated successfully, but these errors were encountered: