Within a synchronous execution, ensure that a Session is available.

The DatabaseCapabilities, accessed through a Session and created by the first Session that needs them. Access does not need to be synchronized because, in the worst case, capabilities will be determined multiple times by different concurrent sessions but the result should always be the same.

Free all resources allocated by Slick for this Database object. In particular, the slick.util.AsyncExecutor with the thread pool for asynchronous execution is shut down. If this object represents a connection pool managed directly by Slick, it is also closed.

Create the default DatabaseActionContext for this backend.

Create a Reactive Streams Publisher using the given context factory.

Create a new session. The session needs to be closed explicitly by calling its close() method.

Create the default StreamingDatabaseActionContext for this backend.

The ExecutionContext which is used for performing blocking database I/O, similar to how run or stream would run it. This can be used for calling back into blocking JDBC APIs (e.g. for materializing a LOB or mutating a result set row) from asynchronous processors of unbuffered streams.

Within a synchronous execution, close the current Session unless it is pinned.

Run an Action asynchronously and return the result as a Future.

Run an Action in an existing DatabaseActionContext. This method can be overridden in subclasses to support new DatabaseActions which cannot be expressed through SynchronousDatabaseAction.

Run a SynchronousDatabaseAction on this database.

Stream a part of the results of a SynchronousDatabaseAction on this database.

Free all resources allocated by Slick for this Database. This is done asynchronously, so you need to wait for the returned Future to complete in order to ensure that everything has been shut down.

Like stream(StreamingAction) but you can disable pre-buffering of the next row by setting bufferNext = false. The ResultSet will not advance to the next row until you request() more data. This allows you to process LOBs asynchronously by requesting only one single element at a time after processing the current one, so that the proper sequencing is preserved even though processing may happen on a different thread.

Create a Publisher for Reactive Streams which, when subscribed to, will run the specified DBIOAction and return the result directly as a stream without buffering everything first. This method is only supported for streaming actions.

The Publisher itself is just a stub that holds a reference to the action and this Database. The action does not actually start to run until the call to onSubscribe returns, after which the Subscriber is responsible for reading the full response or cancelling the Subscription. The created Publisher can be reused to serve a multiple Subscribers, each time triggering a new execution of the action.

For the purpose of combinators such as cleanup which can run after a stream has been produced, cancellation of a stream by the Subscriber is not considered an error. For example, there is no way for the Subscriber to cause a rollback when streaming the results of someQuery.result.transactionally.

When using a JDBC back-end, all onNext calls are done synchronously and the ResultSet row is not advanced before onNext returns. This allows the Subscriber to access LOB pointers from within onNext. If streaming is interrupted due to back-pressure signaling, the next row will be prefetched (in order to buffer the next result page from the server when a page boundary has been reached).

Stream a SynchronousDatabaseAction on this database.

Return the default ExecutionContext for this Database which should be used for running SynchronousDatabaseActions for asynchronous execution.