>> Do you see >> a decisive advantage in changing this right now, though? > > No, it's a minor thing but would be a great place for a contributor to > start.
I see a couple of problems with such a StatementSetter design: 1. It doesn't deal with the fact, that current bind logic depends on both Class<?> AND SQLDialect 2. It doesn't handle NULL well (or the combination of NULL and SQLDialect) 3. It won't be able to handle an optimised distinction of "type == SomeClass.class" and "SomeClass.class.isAssignableFrom(type)" 4. It will add lots of new types to replace a method which is still quite simple and which keeps all bind logic at a single place Keeping these points in mind, the suggested logic would look more like this: // isNull could also translate to type == null && value == null, though StatementSetter setter = lookup(type, dialect, isNull); setter.set(stmt, nextIndex(), value); So I think in this case, a bit of imperative programming with lots of comments beats OO design. I very much appreciate the intent, though. For contribution ideas, please refer to this Trac roadmap milestone: http://tinyurl.com/jooq-contribution-candidates Some examples: - Simulate MEDIAN function for SQL Server (and other dialects) (https://sourceforge.net/apps/trac/jooq/ticket/871) - Optimise GREATEST() and LEAST() simulations for Sybase, ASE, SQL Server, Derby (https://sourceforge.net/apps/trac/jooq/ticket/1049) - Improve performance on jOOQ's reflection usage (https://sourceforge.net/apps/trac/jooq/ticket/1170) - Add support for Factory.floor(Number, int) and ceil(Number, int), to specify the number of resulting decimals (https://sourceforge.net/apps/trac/jooq/ticket/1332) - Generate a copy constructor for POJOs (https://sourceforge.net/apps/trac/jooq/ticket/1363) - Generate toString() on POJOs (https://sourceforge.net/apps/trac/jooq/ticket/1364) - Generate equals(), hashCode() on POJOs (https://sourceforge.net/apps/trac/jooq/ticket/1380)
