augustearth
commented
3 years ago - [x] Create parallel implementation of the following for ensure()
optionallyRunSingletonProcess(ReaperMethod reaperMethodInstance, Map methodArgs = [:]) - [x] De-couple ensure() methods from optionallyRunSingletonProcess() methods
- [x]
call(ReaperMethod reaperMethodInstance, Map methodArgs = [:])in Reaper adds argument hash to procV - [x]
ensure(ReaperMethod reaperMethodInstance, Map methodArgs = [:])looks for an existing procV with matching argument hash when deciding whether to run
When a reaper method is called, current behavior will create a reaper process vertex in the graph that has a label as per the reaper method, but does not contain any unique reference to the arguments that were used to call the reaper method. What this means is that the ensure() or optionallyRunSingletonProcess() methods are limited. Two calls to a reaper method with different arguments are viewed as the same call. So, the reaper method truly is a "singleton process" which is expected to be run only once.
optionallyRunSingletonProcess() methods can stay this way as they have "singleton" in the name. ensure() methods should be more flexible, taking the reaper method arguments into account so a reaper method can be called multiple times on different inputs.
There is probably deep design discussion to be had here.... Taking into account the reaper method and the arguments is nice, but it does not take into account the state of the graph. There is no guarantee that the same reaper method called with the same arguments at different times will have the same effect, which I suppose is the assumption here. Is that useful? Should we enable programmers to classify reaper methods and have different behavior of ensure() depending on the class? I do not know.
For now, making this change will at least bring us more in-line with vine behavior. There is no guarantee that a vine method, which queries a database, called with the same parameters at different times will have the same result. The database can change in that interval. Carnival vine caching makes the assumption that the programer is choosing to ignore any changes refreshing when they choose to do so by invalidating (deleting) cache files. Implementing a similar scheme at the reaper method level seems to make sense.