2014-05-25 12:22 GMT+02:00 Witold Szczerba <[email protected]>: > I think it would be enough to let the converters to use the 'inline' > mechanism, so we could do any conversion we want as far as the JDBC driver > us fine with it. > The jOOQ would need to know how it is supposed to treat such a column, > though... Maybe by adding third type parameter? > The current Converter types are not supposed to know anything about SQL, bind values, or jOOQ API. Their only responsibility is to convert between <U> (user type) and <T> (JDBC type). If you wanted to adapt this right now, you'd need to patch jOOQ internals.
Another option would be to implement a JDBC proxy, that intercepts all PreparedStatement.setDate() calls, and ResultSet.getDate() calls, to patch the required bind value, or to set it as a different data type, e.g. String. That would also let us deal with db custom types in converters, wouldn't > it? Or is it already possible? I can see where your line of thoughts is going, and I believe that we already have this on the roadmap: https://github.com/jOOQ/jOOQ/issues/3248 Specifically with PostgreSQL's many vendor-specific data types, it is very hard to get all the type binding right through the JDBC API, if implemented in jOOQ's core code. Many of those PostgreSQL data types are actually not even supported by PostgreSQL's JDBC driver. So, to help users leverage these things, we want to think about actual type providers that are like Converters, but they also implement all the serialisation and deserialisation logic, i.e.: - How to render SQL with bind variables - How to render SQL with inlined values - How to set bind values onto PreparedStatements - How to register out parameters from CallableStatements - How to read values from ResultSet - How to serialise values to SQLOutput (for Oracle) - How to deserialise values from SQLInput (for Oracle) Unlike a Converter<T, U> type, the TypeProvider<U> type would not need any concrete <T> type (JDBC type), only a <U> type (user type) for use with jOOQ API interaction when forming predicates, etc. Obviously, jOOQ would be providing a lot of default implementations for such type providers. Besides, the existing jOOQ internals will be refactored and pulled out into such providers. In the case of DATE WITHOUT TIMESTAMP, we can then easily make adaptations to allow for mapping things like LocalDate onto whatever SQL representation seems most appropriate. As always, your feedback with this matter is very welcome! Getting this design right will be essential for many future data type related features. Unfortunately, this will not make it into jOOQ 3.4 anymore, but I'm positive that we'll implement it for jOOQ 3.5, some time this summer. Cheers Lukas -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
