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

Support MongoDB session-wide write concern #3646

Merged
merged 6 commits into from
Dec 5, 2017
Merged

Conversation

calvn
Copy link
Contributor

@calvn calvn commented Dec 4, 2017

Closes #3595

Add support for MongoDB's write concern for the mongodb database backend.

One thing to note is that this uses mgo's session-wide write concern, so if that's set when configuring the backend, the write concern applies to all statements.

@calvn calvn added this to the 0.9.1 milestone Dec 4, 2017
Copy link
Member

@brianshumate brianshumate left a comment

Choose a reason for hiding this comment

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

👍 Nice!

jefferai
jefferai previously approved these changes Dec 4, 2017
}

var concern writeConcern
err = json.Unmarshal([]byte(input), &concern)
Copy link
Contributor

Choose a reason for hiding this comment

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

This might be better to do in the Initialize function and cache the writeConcern object in the struct. Will save on marshaling it on every call.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This only gets through if Connection() creates a new session, otherwise it will return pretty early up top. Since other session settings were set here, I thought calling SetSafe here as well.

Copy link
Contributor

Choose a reason for hiding this comment

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

It's also probably better to return any unmarshaling errors during Init too.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd say decode and unmarshal in Init, store the mgo.Safe pointer in the struct and call SetSafe in Connection()

@@ -17,6 +17,16 @@ type mongoDBStatement struct {
Roles mongodbRoles `json:"roles"`
}

// writeConcern is the mgo.Safe struct with JSON tags
// More info: https://godoc.org/gopkg.in/mgo.v2#Safe
type writeConcern struct {
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need this struct or can we just use the mgo.Safe version?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The mgo.Safe struct doesn't have json tags for the fields :(

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, we might not need the JSON tags if there's no snake-casing on the fields so this could probably go away.

Copy link
Contributor

Choose a reason for hiding this comment

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

Okay, in that case i'd say it's fine to leave this struct as is

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We agreed offline that this is okay to remove since we are following mongoDB's naming convention (e.g. wtimeout is not snake-cased). In this case, we can use mgo.Safe's struct directly.

// Only set c.safe if anything got marshaled into concern. We don't want to
// pass an empty, non-nil mgo.Safe object into mgo.SetSafe in Connection().
if (mgo.Safe{} != *concern) {
c.safe = concern
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps this should be an error case? If they set the WriteConcern JSON we should expect to have successfully marshaled something

briankassouf
briankassouf previously approved these changes Dec 5, 2017
Copy link
Contributor

@briankassouf briankassouf left a comment

Choose a reason for hiding this comment

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

One small comment, otherwise LGTM

Copy link
Contributor

@briankassouf briankassouf left a comment

Choose a reason for hiding this comment

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

Looks good! Thanks for making those changes!

@calvn calvn merged commit a9e7dbb into master Dec 5, 2017
@calvn calvn deleted the mongodb-write-concern branch December 5, 2017 20:31
@calvn
Copy link
Contributor Author

calvn commented Dec 5, 2017

Thanks for taking the time to review!

chrishoffman pushed a commit that referenced this pull request Dec 6, 2017
* oss/master:
  changelog++
  Support MongoDB session-wide write concern (#3646)
  Clarify api_addr related errors on VaultPluginTLSProvider (#3620)
  allowed/disallowed_policies as TypeCommaStringSlice (#3641)
  Update example payload and response for pem_keys field which needs \n after header and before footer in order to be accepted as a valid RSA or ECDSA public key (#3632)
  Docs: Update /sys/policies/ re: beta refs to address #3624 (#3629)
  Update secrets page
  Remove beta notice
  Expanding on the quick start guide with how to set up an intermediate authority (#3622)
  Docs: mlock() notes, fixes #3605 (#3614)
  Fix spelling (#3609)
  Add command to example to register plugin (#3601)
  update relatedtools, add Goldfish UI. (#3597)
  Fix docs for Transit API (#3588)
  Update cassandra docs with consistency value.
  Remove Trailing White space in Kubernetes Doc (#3360)
  Missing  command for vault PUT operation (#3355)
  Update some rekey docs
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.

4 participants