Jovan Visnjic
09/21/2020, 1:54 PMLocalResult
. But then we'd like to register the same workflow on the server and run it there on a large scale, using PrefectResult
and cache to the database. We're struggling to get the LocalResult
and PrefectResult
behave in the same way, so we could just switch between one and the other. Does this make sense at all - to have a switch between offline and server run? Or should one result class handle all cases, perhaps a custom one?Kyle Moon-Wright
09/21/2020, 4:42 PMLocalResult
as it would be available to both flows because it caches to a local directory, or potentially a custom class though I'm not sure what that would look like. Maybe you could parameterize/setup some conditional logic for your Result type to define at run time, depending on whether you are doing a local run or a registered run. 🤔Jovan Visnjic
09/21/2020, 5:43 PMLocalResult
on prefect server once. It worked, but since you're referring to this case, I'd mention one minor inconvenience. By default, it stores results to ~/.prefect/results
. When you do workflow.register(...)
on your local PC, ~
gets resolved to your local home directory before registering the workflow. So the server expects path to be exactly the same as on the local PC, instead of resolving ~
on the server and using servers's home dir. But I know I can bypass this by setting some concrete path and make it the same as on the server.
I'd otherwise be interested in how other people do some unit testing of workflows and if others also have the need for local/registered run differentiation. One reason why we need it is also debugging. Are there some better options for such cases?Kyle Moon-Wright
09/21/2020, 5:48 PMJovan Visnjic
09/22/2020, 9:18 AMLocalResult
for now.