Adam Gent

Support for @ConstructorProperties

2

The object definition determination was not finished for `@ConstructorProperties`.

Akin to JUnit's assertEquals.

Better Enum Support through @Enumerated

1

JIRM should automatically convert Enum values to the correct SQL datatype on SQL execution. Whether the `ordinal` or `name` should be used would be based on the `@Enumerated` JPA annotation...

`update...execute()` should return something more useful than `int`. So you can do something like `.execute().expect(2).boolean()` or `.execute().expect(2).throwExceptionIfNot()`

``` sql UPDATE xml_linkedin_profile SET person_xml= XML('TEST' -- {personXml} ) , update_time=now() -- {updateTime} WHERE id='TEST' -- {id} ``` Will turn into (notice TEST at bottom): ``` sql UPDATE xml_linkedin_profile...

Add optional validation that will use java.validation if its available.

To keep accidentally data coercion with JDBC happening with SQL templates type annotations might be useful using the format `-- {name:type}` and `--{:type}`. **Example:** ``` sql SELECT * FROM STUFF...

Currently JIRM uses Jackson to Map objects to and from ResultSets. This allows JIRM to handle @ManyToOne joins for composite objects. Model mapper might be an interesting alternative. http://modelmapper.org/

Doc classes with annotations.

`dao().getSelectBuilderFactory()` and `dao().getUpdateBuilderFactory()` is clunky and weird especially if you want to issue a custom SQL update (and thus do not need `forObject` and friends). Still do not now what...