Dalesbred 1.0 is not source compatible with 0.x because of the following changes:
Changed package structure.
Some less commonly used APIs were simplified.
Few obscure APIs were completely eliminated.
However, the migration should be relatively simple process. This guide provides the details.
New package structure
Base package is now
org.dalesbred instead of
fi.evident.dalesbred. Furthermore some classes were
moved to new packages (e.g.
fi.evident.dalesbred.SqlQuery is now
All the changes are not listed here — let your IDE’s autocomplete fix the imports.
Classes that are not part of public API, but need to be
public for technical reasons are placed
org.dalesbred.internal. Do not use classes defined there since they are not guaranteed
to stay compatible between releases.
Dalesbred now requires Java 1.8. This enables some nice improvements such as enabling uses of
Optional<T> in APIs.
InstantiatorRegistry and related classes and methods were completely removed since they
were seldom used and added too much complication for their weight. Instead of registering instantiator for
globally, you can simply use a custom
ResultSetProcessor in queries for
Simplified type-conversion registration
TypeConversion is no longer part of public API and you don’t need to implement it to register
type-conversions. Instead, you can register normal functions as conversions using
Enum binding changes
Database no longer has
EnumMode for setting globally how enum types are persisted. Rather you can
customize the persistence through
TypeConversionRegistry just like for any other types. By default
enums are persisted as varchars using their constant names. (This corresponds to the previous
Previously enums on PostgreSQL were persisted as native enums in database using database enum type that was
guessed based on the class name of the enum. So if your enum class was named
FooBar, you needed to have
enum type named
foo_bar in database. Now they are persisted as varchars using constant by name by default,
but you can use the previous functionality by calling
Transaction management changes
TransactionContextan interface instead of abstract class.
Removed support for configuring default propagation. Default propagation is now always
REQUIRED, but you can override this on per-transaction basis.
Removed support for setting configuring default isolation level. If you need to set the default isolation, set it for the connections at your connection-provider.
Database.createTransactionalProxyForwere removed, since the functionality really belongs to the runtime environment instead of Dalesbred. If you really need the functionality, copy TransactionalProxyFactory of Dalesbred 0.8.
Removed support for transaction retries. They were hardly useful and not supported for Spring integration.
Guice and AOP Alliance support removed
InstantiationFailureExceptionbecause the former was already used in
Type-objects instead of
Class<?>-objects. Previous functionality is available with
VariableResolvers-class and moved its
org.dalesbred.connection.DriverManagerConnectionProvidercan be used instead.
NonUniqueResultExceptionso that its possible to throw the exception without reading all rows from database. If you really need to have the count, you can ask for list of results and check for uniqueness yourself.
SqlQuery.confidential. Some database drivers will print the values passed to database in exceptions anyway, so the only safe way to make sure that values are not revealed inadvertently is not to show exceptions at all.
fi.evident.dalesbred.Reflectiveto test folder so that it’s not visible in API. Dalesbred did not use it for anything and it doesn’t really make sense for Dalesbred to include such an annotation. You can always define one yourself if you need one in your project.
fi.evident.dalesbred.instantiation.InstantiationListenercompletely. This was hardly ever used. If you need to perform initialization on objects returned by Dalesbred, you can always do it yourself.
Database.getDialect. There should not be a need to access the Dialect directly.