Type Members

1.  case class Connection(connectionUrl: String, username: String, password: String, writeConcern: WriteConcern, verifyConnection: Boolean = true, allowedRoles: Array[String] = Array.empty, rootRotationStatements: Array[String] = Array.empty) extends BaseConnection with Product with Serializable
2.  case class MongoRole(role: String, db: String) extends Product with Serializable
3.  case class Role(dbName: String, creationStatementsJson: JsonObject, revocationStatementsJson: JsonObject, defaultTtl: Duration, maxTtl: Duration) extends BaseRole with Product with Serializable
   dbName

   the name of the database connection to use for this role.

   creationStatementsJson

   Specifies the database statements executed to create and configure a user. The object can optionally contain a "db" string for session connection, and must contain a "roles" array. This array contains objects that holds a "role", and an optional "db" value, and is similar to the BSON document that is accepted by MongoDB's roles field. Vault will transform this array into such format. For more information regarding the roles field, refer to MongoDB's documentation.

   revocationStatementsJson

   Specifies the database statements to be executed to revoke a user. The object can optionally contain a "db" string. If no "db" value is provided, it defaults to the "admin" database.

   defaultTtl

   the TTL for the leases associated with this role. Defaults to system/engine default TTL time.

   maxTtl

   the maximum TTL for the leases associated with this role. Defaults to system/mount default TTL time; this value is allowed to be less than the mount max TTL (or, if not set, the system max TTL), but it is not allowed to be longer.

   See also

   See also The TTL General Case.

4.  case class WriteConcern(minNumberOfWrites: Option[Int] = Some(1), writeMode: Option[String] = None, timeout: FiniteDuration = Duration.Zero, j: Option[Boolean] = Some(true), fsync: Option[Boolean] = None) extends Product with Serializable

   This class does not correspond directly to MongoDB Write Concern but rather to mgo Safe.

   This class does not correspond directly to MongoDB Write Concern but rather to mgo Safe. See Vault MongoDB.

   minNumberOfWrites

   how many servers should confirm a write before the operation is considered successful. When set to 0 - requests no acknowledgment of the write operation. If you also set waitForAcknowledge to true, that prevails to request acknowledgment from the standalone mongod or the primary of a replica set. When set to 1 - requests acknowledgment that the write operation has propagated to the standalone mongod or the primary in a replica set. This is the default. When set to greater than 1 - requires acknowledgment from the primary and as many additional data-bearing secondaries to meet the specified value. For example, consider a 3-member replica set with no arbiters. Specifying 2 would require acknowledgment from the primary and one of the secondaries. Specifying 3 would require acknowledgment from the primary and both secondaries.

   writeMode

   When set to "majority" - requests acknowledgment that write operations have propagated to the calculated majority of the data-bearing voting members (i.e. primary and secondaries with members[n].votes greater than 0). When set to a custom write concern name - Requests acknowledgment that the write operations have propagated to tagged members that satisfy the custom write concern defined in settings.getLastErrorModes. This takes priority over minNumberOfWrites.

   timeout

   specifies a time limit for the write concern. This is only applicable for minNumberOfWrites values greater than 1.

   j

   if set to true, servers will block until write operations have been committed to the journal. Cannot be used in combination with fsync. Prior to MongoDB 2.6 this option was ignored if the server was running without journaling. Starting with MongoDB 2.6 write operations will fail with an exception if this option is used when the server is running without journaling.

   fsync

   If set to true and the server is running without journaling, blocks until the server has synced all data files to disk. If the server is running with journaling, this acts the same as the j option, blocking until write operations have been committed to the journal. Cannot be used in combination with j.