Skip to content
Permalink
Browse files

Fixed problems with format

  • Loading branch information
kiroco12 committed Dec 3, 2019
1 parent c855ff7 commit 317a3d1751c3b626f3dbef8c57eb599dbc86f9c7
@@ -45,7 +45,7 @@ import org.scalatest._
* import cats.implicits._
* }}}
*
* n the doobie high level API the most common types we will deal with have the form `ConnectionIO[A]`,
* In the doobie high level API the most common types we will deal with have the form `ConnectionIO[A]`,
* specifying computations that take place in a context where a `java.sql.Connection` is available,
* ultimately producing a value of type `A`.
*
@@ -59,12 +59,12 @@ import org.scalatest._
* This is a perfectly respectable doobie program, but we can’t run it as-is; we need a `Connection`
* first. There are several ways to do this, but here let’s use a `Transactor`.
*
* > Note: DriverManagerTransactors have the advantage of no connection pooling and configuration, so
* > are perfect for testing. The main disadvantage is that it is slower than pooling connection managers,
* > no provides upper bound for concurrent connections and executes blocking operations in an unbounded
* > pool of threads. The `doobie-hikari` add-on provides a `Transactor` implementation backed by a HikariCP
* > connection pool. The connection pool is a lifetime-managed object that must be shut down cleanly, so
* > it is managed as a Resource.
* '''Note''': DriverManagerTransactors have the advantage of no connection pooling and configuration, so
* are perfect for testing. The main disadvantage is that it is slower than pooling connection managers,
* no provides upper bound for concurrent connections and executes blocking operations in an unbounded
* pool of threads. The `doobie-hikari` add-on provides a `Transactor` implementation backed by a HikariCP
* connection pool. The connection pool is a lifetime-managed object that must be shut down cleanly, so
* it is managed as a Resource.
*
* {{{
* import doobie.hikari._
@@ -25,17 +25,18 @@ import org.scalatest.{FlatSpec, Matchers}
*
* There are three main types of exceptions that are likely to arise:
*
* 1. Various types of `IOException` can happen with any kind of I/O, and these exceptions tend to be unrecoverable.
* '''1.''' Various types of `IOException` can happen with any kind of I/O, and these exceptions tend to be
* unrecoverable.
*
* 2. Database exceptions, typically as a generic `SQLException` with a vendor-specific `SQLState` identifying the
* '''2.''' Database exceptions, typically as a generic `SQLException` with a vendor-specific `SQLState` identifying the
* specific error, are raised for common situations such as key violations. Some vendors (PostgreSQL for instance)
* publish a table of error codes, and in these cases doobie can provide a matching set of exception-handling
* combinators. However in most cases the error codes must be passed down as folklore or discovered by
* experimentation. There exist the XOPEN and SQL:2003 standards, but it seems that no vendor adheres closely to
* these specifications. Some of these errors are recoverable and others aren’t.
*
* 3. doobie will raise an `InvariantViolation` in response to invalid type mappings, unknown JDBC constants returned
* by drivers, observed `NULL` values, and other violations of invariants that doobie assumes. These exceptions
* '''3.''' doobie will raise an `InvariantViolation` in response to invalid type mappings, unknown JDBC constants
* returned by drivers, observed `NULL` values, and other violations of invariants that doobie assumes. These exceptions
* indicate programmer error or driver non-compliance and are generally unrecoverable.
*
* ==MonadError and Derived Combinators==

0 comments on commit 317a3d1

Please sign in to comment.
You can’t perform that action at this time.