Hi Witold,
2014-05-25 11:29 GMT+02:00 Witold Szczerba <[email protected]>:
> Hi Lukas,
> in plain JDBC one can set date like this "{d '2014-05-25'}" or get date
> like "2014-05-25" and parse it.
>
Yes, that's about the same thing as forcing jOOQ to inline the bind value.
jOOQ doesn't use the JDBC escaping syntax, because that won't work if you
copy-paste the generated SQL into pgAdmin III, for instance. But it is the
same as writing the SQL standard date literal: DATE '2014-05-25'
> This way there is no need to deal with tragic sql.Date objects.
>
I know...
> When declaring a jOOQ converter for date field, we can pick any user
> object we want, like LocalDate, but we are forced to use sql.Date as
> database type. Declaring String will not work, the code generator will
> produce broken definition.
>
Hmm, yes, unfortunately, type-rewrites (from SQL DATE to SQL VARCHAR)
currently cannot be combined with Converters. So you're stuck with either
using simple String types (by enforcing VARCHAR) or with converting to
java.sql.Date.
I wonder whether jOOQ should add new types to support the distinction
between with and without timezone SQL temporal types? I don't mean that
jOOQ would actually re-implement java.time.* or JodaTime, but we did the
same thing to formally support SQL standard INTERVAL data types. I guess
the only way to get this right in the long run is to "extend" JDBC in this
area by using dedicated types... What's your opinion on this?
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.
