-
Notifications
You must be signed in to change notification settings - Fork 84
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
Count (and other return values) lost on call to query/scan #91
Comments
Hi Ricardo, To clarify: where do you see a breaking change being necessary? Is the issue that you'd like to return both the items and count information simultaneously? What if Let me know if you'd like me to take a proper look and I'll try schedule some time this coming week. Cheers :-) |
Hi Peter, Yes, I'm looking into getting both items and count, as well as any other data we get like the scanned item count. I hadn't considered the metadata approach, and you're right - that would solve the need for a breaking change. I'm now wondering if it's worth making this change for my use case, though, since it seems like the functionality I need isn't really provided by query/scan at all. I'd like the limit the number of rows returned, and get a total count of rows, but QueryRequest/ScanRequest do not seem to have support for actually limiting the result size, which I've so far found on the newer document API. Without being able to limit the results, I'm not sure how much use there is to the count/scanned-count. It would however fix the broken options. |
Hi Ricardo, could you possibly clarify this line: you mean that QueryRequest and ScanRequest don't offer the facility you're looking for but some other new API exists which does? Have spent zero time using (or keeping up with) DDB in a long while; is there a reason we couldn't / wouldn't want to support the new document API? Or am I misunderstanding? |
Hey Peter, Consider this a WIP/half-uninformed reply, as I've just started looking into the new API and need to run further tests.
The Suppose we have 30 items on a table, and ask it to limit the scan to 10. We also send a filter expression that would eliminate the first five (because of non-index reasons). We'll only get five results back, since the scan only retrieved the first ten items and then filtered them. From what I've read (and on some basic initial tests), the new ScanSpec/QuerySpec
No particular reason. It's just not something we can easily tack on to the existing query/scan - they're different classes on different namespaces with different expectations. |
Gotcha, thanks for the clarification. Will leave it to your best judgement re: if/when/how to add support for the ScanSpec/QuerySpec API. All the best for the new year btw! |
Thanks, and likewise! |
@ricardojmendez faraday is (now) returning metadata on the results from query/scan containing count, last-prim-kvs etc. Are we OK to close? That is not to say we shouldn't look at the Document API as per #103 of course, but I'm not sure we need it to get this data back right now unless I misunderstood the issue? |
Hey @kipz - this issue is about 4 years old and I haven't used Faraday in a while, so feel free to de-prioritize or close. Cheers! |
Thank you. |
I see that the issue is closed and probably a long overdue, but scan actually does return the metadata.
|
While we do get an element
count
back from QueryResult, we are discarding this information on the call tomerge-more
, and query is returning only the list of items. We don't currently have a way to query and return all information.Any thoughts on how to best handle this? It would be a major breaking change, so perhaps the best way is to have a separate query-raw that does not receive
span-reqs
and returns the value straight from as-map.As a side note, it appears that
merge-more
also discards other information that users could ask for on query, such as the consumed capacity (there's even a documented parameter for that onquery
).The text was updated successfully, but these errors were encountered: