Type Members

1.  class CloseMachine extends StateMachine[Ready.type]

   Implements a simple machine for closing a prepared statement or a portal.

2.  class ExecuteMachine extends StateMachine[QueryResponse]

   Implements part of the "Extended Query" message flow described here https://www.postgresql.org/docs/current/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY.

   Implements part of the "Extended Query" message flow described here https://www.postgresql.org/docs/current/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY.

   This machine is used in combination with PrepareMachine. That is, before executing this machine, a prior execution of PrepareMachine must have taken place.

   NOTE: this machine is slightly different from other ones in that it will send multiple messages on start and then a Flush. The reason is because the message flow is different in this case and the backend does not send individual responses until the Flush is received. The machine expects responses to come back in order, but it's not entirely clear if the backend is allowed to send them in a different order.

   Also note that this machine is used for both executing a portal as well as resuming a previously executed one.

3.  case class HandshakeMachine(credentials: Credentials, database: Database, statementTimeout: StatementTimeout, sessionDefaults: SessionDefaults) extends StateMachine[ConnectionParameters] with Product with Serializable

   Implements the "Start-up" message flow described here https://www.postgresql.org/docs/current/protocol-flow.html#id-1.10.5.7.3

   Implements the "Start-up" message flow described here https://www.postgresql.org/docs/current/protocol-flow.html#id-1.10.5.7.3

   This process involves authenticating the client and accumulating parameters about the server's configuration for this connection. Failure to authenticate will produce an exception. A successful response Response.ConnectionParameters which includes the connection's parameters such as character encoding and timezone.

4.  class PrepareMachine extends StateMachine[ParseComplete]

   Implements part of the "Extended Query" message flow described here https://www.postgresql.org/docs/current/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY.

   Implements part of the "Extended Query" message flow described here https://www.postgresql.org/docs/current/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY.

   This machine is used in combination with ExecuteMachine. That is, after executing this machine, an execution of ExecuteMachine is required to obtain the results.

5.  class Runner extends AnyRef

   The runner connects state machines to a connection and allows dispatching machines on the connection.

6.  class SimpleQueryMachine extends StateMachine[SimpleQueryResponse]

   Implements the "Simple Query" flow described here https://www.postgresql.org/docs/current/protocol-flow.html#id-1.10.5.7.4

   Implements the "Simple Query" flow described here https://www.postgresql.org/docs/current/protocol-flow.html#id-1.10.5.7.4

   Note that the name is somewhat misleading since the flow is not particularly simple due to the fact that it supports an arbitrary number of queries in a single message, i.e.: "multi-line queries".

   For example, the client may send CREATE TABLE (...); CREATE INDEX ... in a single query. All types of queries are supported.

7.  trait StateMachine[+R <: Response] extends AnyRef

   A StateMachine is responsible for managing the connection state and expose a Request => Future[Response] regardless of the number of actual request / response cycles required with a backend server.

   A StateMachine is responsible for managing the connection state and expose a Request => Future[Response] regardless of the number of actual request / response cycles required with a backend server.

   That is, for any particular client request / response cycle, multiple request / response cycles are usually required with the postgresql backend. This requires coordinating state with the backend which is what is encapsulated in StateMachine implementations.

   StateMachines have a public type parameter to represent the response type that it will eventually produce. They also have an internal type parameter to represent its internal state representation.

   StateMachine only encapsulates the state transitions, not the state itself, which must be maintained externally (i.e.: in some kind of runner). That is, implementations provide a starting state and a way to transition to another state. The "current state" must be maintained in whatever is encapsulating the connection (specifically, in com.twitter.finagle.postgresql.ClientDispatcher for the finagle client.)

   StateMachines are responsible for eventually producing the response to the client's request as well as eventually reaching a completion state which leaves the connection ready for a new client request. Note that responding to the client with the response does not necessarily occur at the same time the state machine completing. That is, the client response may be produced while the state machine still exchanges messages with the backend on the connection.

   R

   The type of client response eventually produced by the state machine implementation.

   See also

   com.twitter.finagle.postgresql.ClientDispatcher