-
Notifications
You must be signed in to change notification settings - Fork 584
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't reuse QueryCommand in loop #1864
Can't reuse QueryCommand in loop #1864
Comments
AWS SDK for JavaScript v3 supports Pagination using Async Iterators. Can you try |
The root cause for this issue seems to be duplicated with #1857. We will look further into this. |
Hi @clintfoster, Just like it mentioned by @trivikr, you can still work around it by using Pagination using Async Iterators. The SDK handles making consecutive requests for you. |
@trivikr @AllanZhengYP Thanks for the pointer to async iterators. I tried a trivial paged query, and it was clean and simple. However, I need the ability to exit the pagination loop and later re-enter it where I left off. I think this should be possible by saving As a temporary workaround I will stick with creating a new |
Hey @clintfoster,
Looks like the
You can exist the async iterator and resume it easily in my opinion too, It would look like: const iter = paginateScan({client: dynamoClient}, params);
let res: ScanCommandOutput
let isEnd = false;
while(isEnd) {
const {value, done} = await iter.next();
isEnd = done;
res = value;
if (value.Items[0] === {} /*when you want to exit the pagination*/) {
break; //exit
}
}
//do something
//resume paginating; using for loop this time.
for await (const result of paginateScan(
{client: dynamoClient},
{...qParams, ExclusiveStartKey: res.LastEvaluatedKey}
)) {
//do something
} |
I opened a feature request for adding more types in paginator. |
When sending the same command multiple times, resolveMiddleware() will be called many times. So adding serde middleware will throw error because they are already added into stack. This change prevents adding the serde middleware repeatedly. Alternative is moving command middleware to the command constructor, just like in client(that's why client doesn't have the problem). But the command middleware also have depdency over client configs supplied from resolveMiddleware(). So serde middleware and customizations must live here. ref: aws/aws-sdk-js-v3#1864
When sending the same command multiple times, resolveMiddleware() will be called many times. So adding serde middleware will throw error because they are already added into stack. This change prevents adding the serde middleware repeatedly. Alternative is moving command middleware to the command constructor, just like in client(that's why client doesn't have the problem). But the command middleware also have depdency over client configs supplied from resolveMiddleware(). So serde middleware and customizations must live here. ref: aws#1864
When sending the same command multiple times, resolveMiddleware() will be called many times. So adding serde middleware will throw error because they are already added into stack. This change prevents adding the serde middleware repeatedly. Alternative is moving command middleware to the command constructor, just like in client(that's why client doesn't have the problem). But the command middleware also have depdency over client configs supplied from resolveMiddleware(). So serde middleware and customizations must live here. ref: aws/aws-sdk-js-v3#1864
When sending the same command multiple times, resolveMiddleware() will be called many times. So adding serde middleware will throw error because they are already added into stack. This change prevents adding the serde middleware repeatedly. Alternative is moving command middleware to the command constructor, just like in client(that's why client doesn't have the problem). But the command middleware also have depdency over client configs supplied from resolveMiddleware(). So serde middleware and customizations must live here. ref: #1864
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread. |
Describe the bug
This is either a bug or a documentation / usability issue. When attempting to reuse a Dynamo
QueryCommand
in a typical paging loop I get a "Duplicate middleware" exception:SDK version number
3.1.0
Is the issue in the browser/Node.js/ReactNative?
Browser
Details of the browser/Node.js/ReactNative version
Paste output of
npx envinfo --browsers
To Reproduce (observed behavior)
Below is a typical loop to scan the sort key of an item with partition key
fooId = 123
:My specific question is why
QueryCommand
must be recreated each time through the loop to avoid the error. Wouldn't it be natural to reuse it, changing only theExclusiveStartKey
as needed?I guess this is kind of a nit, and what I'm really looking for is the most efficient and idiomatic way to implement a standard paging loop in the v3 API. An example in the documentation would go a long way.
Expected behavior
It should be possible to express a simple paged query (or scan) without inefficient or confusing constructs.
The text was updated successfully, but these errors were encountered: