Skip to content
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

use aws-sdk-go-v2 #43

Open
wants to merge 69 commits into
base: master
Choose a base branch
from
Open

use aws-sdk-go-v2 #43

wants to merge 69 commits into from

Conversation

shamaton
Copy link

@shamaton shamaton commented May 15, 2023

Issue #, if available:

#2

Description of changes:

use aws-sdk-go-v2 in the entire code.
If you have any questions, please feel free to ask.

Summary of the changes

Although there are numerous changes in the code, I have made the following modifications:

  • Import aws-sdk-go-v2, but no import aws-sdk-go
  • All error is wrapped by using aws/smithy-go
  • Compatible dynamodb V2 API (see also: dax.DynamoDBAPI)
  • Functions such as Retryer use aws-sdk-go-v2.
  • For functionalities that are difficult to maintain compatibility with, removed them temporarily (e.g., PutItemRequest, BatchGetItemPages)
  • Of course all test passed

Verification

I have created a validation repository to confirm if the changed code is actually usable.
https://github.com/shamaton/aws-dax-go-v2-test

  • API: GetItem
  • API: PutItem (also case: ConditionalExpression)
  • API: UpdateItem
  • API: DeleteItem
  • API: Query
  • API: Scan (also Count)
  • API: BatchGetItems
  • API: BatchWriteItems
  • API: TransactGetItems
  • Checked if the DAX cache is enable

The future of this pull request

I think there are the following options:

  1. Merge this pull request into the master branch.
  2. Merge the changes of this pull request into another branch, such as v2, and proceed with the operation.
  3. Create a separate repository to make it usable, for example, aws/aws-dax-go-v2.
  4. Reject this pull request (unfortunate decision).

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@shamaton shamaton changed the title [WIP] use aws-sdk-go-v2 use aws-sdk-go-v2 Jun 10, 2023
@taiyow taiyow mentioned this pull request Jun 30, 2023
@shamaton
Copy link
Author

Any comments or reviews from aws staff?

@anudeeb
Copy link

anudeeb commented Jul 14, 2023

@shamaton Thank you for raising the PR. We are currently reviewing it and will get back to you soon.

Copy link

@anudeeb anudeeb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reviewed few files and added some comments. Please let us know if you have further questions.

dax/api.go Outdated
Comment on lines 86 to 89
o := d.config.requestOptions(false, opts...)
ctx, cancel := d.ContextWithTimeout(ctx)
defer cancel()
return d.client.PutItemWithOptions(ctx, input, o)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see these 4 lines are similar in all the methods. Is it possible to avoid the duplicate code?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can avoid duplicate code by writing code like this:

func (d *Dax) TransactGetItems(ctx context.Context, input *dynamodb.TransactGetItemsInput, opts ...func(*dynamodb.Options)) (*dynamodb.TransactGetItemsOutput, error) {
	return f(d, ctx, input, d.client.TransactGetItemsWithOptions, opts...)
}

func f[T any, U any](d *Dax, ctx context.Context, input T, outputFn func (context.Context,  T, client.RequestOptions) (U, error), opts ...func(options *dynamodb.Options)) (U, error) {
	o := d.config.requestOptions(true, opts...)
	ctx, cancel := d.ContextWithTimeout(ctx)
	defer cancel()
	return outputFn(ctx, input, o)
}

But it requires generics, go version must be 1.18 or higher. With the current supported version, I think any further changes would add overhead.

dax/api.go Outdated
Comment on lines 155 to 177
//func (d *Dax) BatchGetItemPages(ctx context.Context, input *dynamodb.BatchGetItemInput, fn func(*dynamodb.BatchGetItemOutput, bool) bool, opts ...func(*dynamodb.Options)) error {
// p := request.Pagination{
// NewRequest: func() (*request.Request, error) {
// var inCpy *dynamodb.BatchGetItemInput
// if input != nil {
// tmp := *input
// inCpy = &tmp
// }
// req, _ := d.BatchGetItemRequest(inCpy)
// req.SetContext(ctx)
// req.ApplyOptions(opts...)
// return req, nil
// },
// }
//
// for p.Next() {
// if !fn(p.Page().(*dynamodb.BatchGetItemOutput), !p.HasNextPage()) {
// break
// }
// }
//
// return p.Err()
//}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can probably remove these lines.

When we get a similar paginator from DynamoDB, we can add it similarly for DAX - aws/aws-sdk-go-v2#1707

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

delete in 39275d2

dax/api.go Outdated
Comment on lines 411 to 413
if d.config.RequestTimeout > 0 {
return context.WithTimeout(ctx, d.config.RequestTimeout)
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would mean that we would never honour timeout set in ctx right? We would only honour the timeout that's set in d.config.RequestTimeout.

For v2, we are thinking to eliminate d.config.RequestTimeout and just rely on the timeout set in ctx. What are your thoughts on this?

Please refer to #46 (comment) for discussion around this topic.

Copy link
Author

@shamaton shamaton Aug 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this code will always set d.config.RequestTimeout as timeout in context. A timeout in the parent context is also valid.
https://go.dev/play/p/NNgqWXaEbUH

If we want to remove d.config.RequestTimeout, we can do so but setting timeout is completely up to the user.
I do not recommend it. We should always have timeout set to the default value recommended by aws unless set by user.

This issue #46 (comment) is that the RequestTimeout is not set unless the context is nil right?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So what we are saying here is that both values will be read but if the user passes a ctx with a timeout, this will override config.RequestTimeout? That sounds fine by me...

Please document this! Above this code

RequestTimeout time.Duration

Copy link
Author

@shamaton shamaton Aug 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@anudeeb
I thought about this again.

It may be better to let user set context.WithTimeout. This is because the amount of time it takes depends on kinds of the data processing. For example, fetching or counting lots of data may be different than fetching single record.

so I think it is good thoughts to eliminate config.RequestTimeout

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed in eaf620e

@miparnisari
Copy link

Question: since there is no way of testing DAX locally, has this PR been tested against an actual DAX cluster?

if err != nil && opt.Logger != nil && opt.LogLevel.Matches(aws.LogDebugWithRequestRetries) {
opt.Logger.Log(fmt.Sprintf("DEBUG: Error in executing request %s/%s. : %s", service, op, err))
}
if opt.Logger != nil {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here and in other places, why do you need this check? set a default NoOp logger :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Logger can be nil if you created a CustomConfig without using a DefaultConfig.
It may be good to set Nop when Logger is nil.

@shamaton
Copy link
Author

shamaton commented Aug 1, 2023

@miparnisari

Question: since there is no way of testing DAX locally, has this PR been tested against an actual DAX cluster?

Yes. I created a validation repository to confirm if the changed code is actually usable.
https://github.com/shamaton/aws-dax-go-v2-test

Please, see verfication part of summary.

@shamaton shamaton requested a review from anudeeb August 9, 2023 03:31
@bsandeepan
Copy link

Hi, if this PR gets approved, by when can we expect these changes ready for production usage?

@shamaton
Copy link
Author

Hi, is status reviewing now?

@srri
Copy link

srri commented Oct 30, 2023

Bumping interest on this PR. Lots of us are waiting for a SDK v2 version of this DAX client. Feels like it's been abandoned..

@ngjmcdonald
Copy link

Adding another voice, hoping to get this SDK upgraded to the new version in the new year! Echoing the previous comment it feels like it's been abandoned but DAX is still encouraged as the cache for DynamoDB

@Joao-Pedro-MB
Copy link

Hello everyone. Any updates on this PR? I have been studying the Shamaton changes, and they are quite solid. I was able to make it work very easily, even with a newer Go version in go.mod.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants