Closed awendt closed 11 years ago
The SDK is only holding onto static attributes. Calling #closed_after on a workflow execution will trigger a new request every time to see if the value has updated service side. This is sub-optimal for tight loops like you have above.
You can work around this by enabling memoization:
AWS.memoize do
# only one request required
workflow_executions.each {|ex| puts ex.started_at; puts ex.closed_at}
end
All attributes are held inside a memoize block. The block indicates it is okay to cache non-static attributes within a given scope. I'm a not fan of this and we will remove the need to use memoize blocks in v2 of the SDK.
@trevorrowe Thanks for the quick response. And thanks for clarifying that you're not a fan of this, Github sent me an e-mail with a comment that didn't make sense, I guess that was before an edit :)
Anyway, thanks for pointing me to AWS.memoize
. I wasn't aware that closeTimestamp could be updated.
It can't be updated or specified, but it can go from nil
, which means not closed to an actual timestamp. Static attributes are those like a resource identifier or a creation timestamp that never change.
I'm going to close this issue for now. I hope this helps.
I'm trying to find specific workflow executions by tag:
So far, so good. Now I'd like to access not only
started_at
, but alsoclosed_at
:That means the SDK makes another call to the
DescribeWorkflowExecution
API for every workflow execution just because I'm accessingclosed_at
of that workflow execution.This is unnecessary because ListClosedWorkflowExecutions already returns closeTimestamp in addition to startTimestamp.
AFAICS, the same information for n workflow executions can be obtained in 1 call instead of n+1 calls.
Am I missing something here?