oriana
A configured schedule derives its delays from the config key "retry_db_delay_millis", where it expects to find a number list.
A configured schedule derives its delays from the config key "retry_db_delay_millis", where it expects to find a number list. The numbers are interpreted as millisecond delays.
Internal implementation actor for a single database interaction.
Internal implementation actor for a single database interaction. This actor handles the actual invocation of an operation, including failure / retry logic.
context type
result type
Initializers prepare the Database on startup, ensuring it is in a usable state once application traffic reaches it.
Initializers prepare the Database on startup, ensuring it is in a usable state once application traffic reaches it. They may be simple (as in, create tables if absent) or elaborate. The init process needs to be complete before the first "user" operation can be attempted.
Type for operations - simple DB interactions that are not part of a transaction.
Type for operations - simple DB interactions that are not part of a transaction. Since they may have multiple, disjoined stages, they can not be retried and can have partial results (depending on which parts of them were executed).
Options modifying the behaviour of a database sink
Options modifying the behaviour of a database sink
should the sink cancel the stream on an error? The default will always cancel
limit of parallel items to process. Default is single-transaction
Models a streamable DB operation.
Models a streamable DB operation. These operations should not modify state. Note the missing [DatabaseCommandExecution] type to prevent direct execution
Transactions are all-or-nothing sets of operations on the database.
Transactions are all-or-nothing sets of operations on the database. They can either succeed (which applies all modifications that may have arisen simultaneously), or fail. If they fail, the oriana actors will attempt the transaction again until its retry allowance is exhausted.
Note the absence of the DatabaseCommandExecution
trait in the Context, which prevents direct access to the database - and thus allows making the transaction retryable
context subclass required by this transaction
result type
The central point of oriana, an actor that enables an init lifecycle for a database, and a parent to individual operation actors.
The central point of oriana, an actor that enables an init lifecycle for a database, and a parent to individual operation actors.
This actor goes through 3 lifecvcle stages. Uninitialized, where it accepts simple operations and transactions (operations for short), changes to its retry configuration and changes to the initializer. It will queue, but not execute any operations it receives. These queued operations will use the retry configuration that was active when they were first received. Once it received the [DatabaseActor.Init] message, it will evolve to the initializing state.
While the actor is initializing, it executes the configured initializer. It will accept operations and keep them queued, and accept changes to the retry configuration. If initialization succeeds, it will enter the ready state. If initialization fails, the failure will trigger an exception on this actor, which will (in turn) lead to the actors supervisor deciding the further fate of the database access. Upon entering the ready state, all previously queued operations are fired
In the ready state, the actor accepts retry policy changes and operations, which start executing immediately
Marks a context as supporting direct execution.
Marks a context as supporting direct execution. Contexts with direct execution can be used for "simple" DBOperations, but because transactionality cannot be guaranteed, will not be subject to retries.
Database context encapsulate a driver, its api and a list of all tables.
Database context encapsulate a driver, its api and a list of all tables. You are encouraged to add members for your tables when you implement your class. For example:
class MyContext extends DatabaseContext { val driver = MySQLDriver val api = driver.api val ponies: TableAccess[Pony] = new PonyTableAccess(driver) val riders: TableAccess[Rider] = new RiderTableAccess(driver) val ponyReviews: TableAccess[PonyReview] = new PonyReviewTableAccess(driver) val allTables = List(ponies, riders, ponyReviews) }
Wrapper type representing a database name.
Wrapper type representing a database name. The name is supposed to be the actor name of the database actor.
name of the actor
Context type for operations - mixes in the DatabaseCommandExecution trait in to grant access to the database object of the context
Attempts a fixed number of retries, with constant time delays
Mix in this trait to an exception to make the exception "fatal", and prevent the normal transaction handling from retrying on this failure.
Mix in this trait to an exception to make the exception "fatal", and prevent the normal transaction handling from retrying on this failure. This feature is useful to distinguish "business domain" errors which will never go away from technical glitches and transient conditions (such as a lost DB connection), which a wait-and-retry can eventually defeat.
Defines a retry schedule for failures of an DBTransaction.
A base class for Contexts that derive their database connection from a typesafe configuration.
A base class for Contexts that derive their database connection from a typesafe configuration. The driver object still needs to be determined "by hand", or by calling the alternate constructor, which offers a way to determine it by configuration
Defines access to a slick table.
Defines access to a slick table. This includes a query object (for CRUD operations) and a schema create action.
type of slick FRM table class
Subscriber implementing the sink semantics.
Subscriber implementing the sink semantics. Do not use manually, instead use executeAsSink()
context type
input type
Companion for the DBTransaction class
The default schedule retries five times, with escalating delays.
The default schedule retries five times, with escalating delays. The retries occur at 100, 200, 300, 400 and 500 ms intervals. This schedule is primarily beneficial to testing and demo environments, and should generally be replaced by a more considered schedule in applications.
Simple schedule that never attempts a retry
Simple initializer that executes create DDL for any missing tables.
Simple initializer that executes create DDL for any missing tables. Does not care or have capability to provide an initial data load.
Performs a database-using operation as a flow element.
Performs a database-using operation as a flow element.
Context type (useful for table access)
input type
output type
operation to execute
factory for accessing the lower-level ([executeDBOperation] operation.
ask timeout for each execution
context to use
database actor name
flow modelling the specified transformation
Creates a sink that executes the specified database transaction for every element published to the stream.
Creates a sink that executes the specified database transaction for every element published to the stream. The sink has some options that can be set to modify its operation. The operation materializes a future that returns the number of successfully-processed transactions.
Context type (useful for table access)
input type
operation to perform
settings for the sink
factory for accessing the lower-level ([executeDBOperation] operation.
ask timeout for each execution
context to use
database actor name
sink instantiated to execute the specified transaction per-element.
Creates a source from a streamable database operation
Creates a source from a streamable database operation
context type (useful for table access)
emitted type
operation
actor factory for communication to the database actor
ask timeout for the initial creation of the sink, not for each operation
context to use
database actor name
source backed by the passed DB operation
Syntactic sugar for access to the database.
Syntactic sugar for access to the database. The block argument is scheduled as a [DBOperation] to the implicit database.
executeDBOperation { ctx: MyContext with DatabaseCommandExecution =>
// ... generate actions, and execute them with ctx.database.run
ctx.database.run(DBIO.successful(42))
}operation return type
operation to perform
most likely an actor system
timeout for ask operation(s) used under the hood to implement the Future
execution context for ask operation(s) used under the hood to implement the Future
name for the database actor
future with operation result
Syntactic sugar for access to the database.
Syntactic sugar for access to the database. The block argument is scheduled as a [DBTransaction] to the implicit database. Transactions may be attempted multiple times in case of failures, making them good candidates for idiom such as optimistic locking.
executeDBTransaction { ctx: MyContext =>
// ... generate actions, which will be wrapped with transactionally and executed
DBIO.successful(42)
}context type to pass to the transaction
result type of the transaction
transaction to attempt
most likely an actor system
timeout for ask operation(s) used under the hood to implement the Future
execution context for ask operation(s) used under the hood to implement the Future
name for the database actor
future with transaction result