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
Working with DAGs in drake should be parallelizable. However, board is currently designed to write to leadrboard.RDS on each call. That means you can't take advantage of drake's, for fear of a writing conflict.
An output file can only be the target of one command in drake. This means that the current behavior of board is problematic, even if you run everything sequentially (avoiding the problem in 1.). For example,
Drake Challenges
I encountered a few challenges using
board
in a drake pipeline.Working with DAGs in drake should be parallelizable. However,
board
is currently designed to write toleadrboard.RDS
on each call. That means you can't take advantage of drake's, for fear of a writing conflict.An output file can only be the
target
of onecommand
in drake. This means that the current behavior ofboard
is problematic, even if you run everything sequentially (avoiding the problem in 1.). For example,is problematic because
leadrboard.RDS
can only be the target of one of theboard
calls.Proposed Solutions
Here is how
leadr::board
could be redesigned to better work with a drake workflow.leadrboard.RDS
. This would resolve potential writing conflicts describe in one.The idea for the last is as follows:
Here,
board(model__, save = FALSE)
would return a leaderboard tibble with only one row formodel__
.Then:
The text was updated successfully, but these errors were encountered: