You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A plain JDBC implementation would be useful in applications that use a relational database but don't use JDBI (e.g. maybe it uses Hibernate), and which don't want to add another dependency.
The text was updated successfully, but these errors were encountered:
* Add JdbcApplicationErrorDao, a plain JDBC implementation of
ApplicationErrorDao
* Since the logic to map from a ResultSet is identical for the
JDBC and JDBI implementations, move that logic from the
Jdbi3ApplicationErrorRowMapper into ApplicationErrorJdbc in
a new method 'mapFrom(ResultSet)'. Also, fix how the port
is set, using rs.getInt instead of intValueOrNull, since
the port field in ApplicationError is an int, not Integer
* Add new constructor accepting only a Throwable to
ApplicationErrorJdbc.ApplicationErrorJdbcException
* Add several new helper methods to ApplicationErrorJdbc
for the JDBC implementation, nextOrThrow and shutdownH2Database
* Add abstract base test class, AbstractJdbcApplicationErrorDaoTest,
and two subclasses for testing against H2 and Postgres
* Make sure to shut down the in-memory H2 database in both
H2Jdbi3ApplicationErrorDaoTest and H2JdbcApplicationErrorDaoTest.
Otherwise, if the H2 JDBI test runs after the JDBC one, the
tests fail because they expect the database to be empty.
By shutting the in-memory database down, we ensure the tests
are completely isolated.
Misc:
* Remove two redundant warning suppression annotations from
ErrorContextUtilitiesTest
Closes#248
* Add plain JDBC ApplicationErrorDao implementation
* Add JdbcApplicationErrorDao, a plain JDBC implementation of
ApplicationErrorDao
* Since the logic to map from a ResultSet is identical for the
JDBC and JDBI implementations, move that logic from the
Jdbi3ApplicationErrorRowMapper into ApplicationErrorJdbc in
a new method 'mapFrom(ResultSet)'. Also, fix how the port
is set, using rs.getInt instead of intValueOrNull, since
the port field in ApplicationError is an int, not Integer
* Add new constructor accepting only a Throwable to
ApplicationErrorJdbc.ApplicationErrorJdbcException
* Add several new helper methods to ApplicationErrorJdbc
for the JDBC implementation, nextOrThrow and shutdownH2Database
* Add abstract base test class, AbstractJdbcApplicationErrorDaoTest,
and two subclasses for testing against H2 and Postgres
* Make sure to shut down the in-memory H2 database in both
H2Jdbi3ApplicationErrorDaoTest and H2JdbcApplicationErrorDaoTest.
Otherwise, if the H2 JDBI test runs after the JDBC one, the
tests fail because they expect the database to be empty.
By shutting the in-memory database down, we ensure the tests
are completely isolated.
Misc:
* Remove two redundant warning suppression annotations from
ErrorContextUtilitiesTest
Closes#248
* Move shutdownH2Database into a test utility class
* Implement transaction rollback in JDBC DAO tests
A plain JDBC implementation would be useful in applications that use a relational database but don't use JDBI (e.g. maybe it uses Hibernate), and which don't want to add another dependency.
The text was updated successfully, but these errors were encountered: