Hi Lukas, Let's assume there is no central repository, and fields know their mapper. Let's also consider that with custom types you need to specify the converter for things like "select X from dual".
The normal flow is: x -> mapping -> y -> conversion -> z I think I already mentioned another application of type mapping some time ago: data validation. Mapping can check that values are coherent and can raise exceptions. If I take the case of my dates in ranges, a business rule is so that "MyRangeBeginDateConverter" must refuse null or +inf Java values and the Java to SQL method must raise an exception in this illegal state. Another similar example: let's consider an enum that is used at different places, and which is stored in the database as numbers. Maybe certain of its usage would not accept certain values: a dedicated converter for those columns may perform this validation to protect against inserting silly value (and yes, in some cases we don't want to add more constraints in the database and want to have application specific checks). x -> mapping + checks -> y -> conversion -> z In fact, a corolary is that the mapping stage may decide to not map at all, but only apply business rules: when data is converted to SQL, it can throw an exception if that data is not acceptable business wise. y -> check -> y -> conversion -> z I think having the possibility of applying simple business validation of values when going into and from jOOQ directly at the mapping stage is a nice feature and removes the burden of external checks everytime a particular column is accessed. It is also simple to understand and does not require an additional dedicated API. Hope this helps, -Christopher
