Skip to content

sdk2 comment #188

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

Closed
DALDEI opened this issue Oct 1, 2017 · 3 comments
Closed

sdk2 comment #188

DALDEI opened this issue Oct 1, 2017 · 3 comments
Labels
closing-soon This issue will close in 4 days unless further comments are made. guidance Question that needs advice or information. response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 10 days.

Comments

@DALDEI
Copy link

DALDEI commented Oct 1, 2017

I am trying the sdk v2, dynamodb. Overall I like it, and was interested in the async code.
A few issues - maybe I simply cant find the right classes.
As a bonus, Im using kotlin (jvm) and have little problems interfacing.

I got the document model working fairly well then I tried converting to the async client
to discover that the document api doesn't accept an async client.
The code to do a batch write (or nearly any ddb code) is extremely verbose and tedious.
Considering that most of the document api is simply providing a simpler way to construct the
same payload - but using essentially the same abstraction 1:1 -- this was painful.
Even with kotlin's conciseness what was a few lines of code became 20+ -- for just a 3 attribute item.

I like the builder's in concept but in many cases, like the one above, where every single attribute value, item, request etc requires a builder and build its very tedious to write ..
BatchPutItemRequest.builder()..... ( WriteItem.builder()..... Item.builder().... AttributeValue.builder.... build() build() build() build() build() ... took 15 minutes to match the parens.

If everything needs to be a builder, maybe there's a way to avoid having to explicitly call builder() and build() for everything -- why not make the Request objects' builders and build them when they are
passed as arguments to the requests.

@spfink
Copy link
Contributor

spfink commented Oct 2, 2017

The document and mapper APIs are yet to be refactored for v2:

#36
#35

Feel free to add comments to either of those threads with additional suggestions. Async support is of course something we will look at for them.

As far as verbosity goes, that is also something that we are continuing to look into. We are considering removing the necessity to call .build().

@kiiadi
Copy link
Contributor

kiiadi commented Nov 9, 2017

@DALDEI we've got a proposal out for adding additional setters on our model object builders will remove the need to create the builder and all build. They accept a consumer of Builder - take a look at the PR for an example : #278

@justnance justnance added guidance Question that needs advice or information. response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 10 days. and removed Awaiting Requester Reply labels Apr 19, 2019
@debora-ito debora-ito added the closing-soon This issue will close in 4 days unless further comments are made. label Jul 16, 2019
@debora-ito
Copy link
Member

It's been a while since we've heard back so I'll go ahead and close this one. Feel free to reach out if you have more questions or any other feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closing-soon This issue will close in 4 days unless further comments are made. guidance Question that needs advice or information. response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 10 days.
Projects
None yet
Development

No branches or pull requests

6 participants