Hi Lukas,
> But good point for the
> dates. With DEBUG logging, that didn't matter too much so far, so the
> implementation is quite simple (consider the if (context.inline())
> block):
I see you also escape single quotes in Strings which I was about to ask.
About dates, I don't know if this is the best strategy, but this is what we do:
with formatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS")
Oracle:
"to_timestamp('" + formatter.format(date) + "','YYYY-MM-dd HH24:MI:SS.FF')"
SQLServer:
"convert(datetime,'" + formatter.format(date) + "',121)"
We seem to have a different simpler conversion when the date is only
used as a day and not date/time. I wonder how it should behave
depending on the actual type of the column on Oracle (Timestamp vs
Date)
I also wonder what would happen if I generate the model for SQLServer,
then use it against Oracle which for the DATE_TIME uses TIMESTAMP.
Would the generated script be compatible (the factory would know that
the dialect is Oracle but the declared type of the field would be the
SQLServer type)?
We also convert a boolean to 1 or 0, both for Oracle and SQLServer.
>>> As a Factory configuration, this setting could be applied
>>> on a per-query basis, i.e. if you have 10-20 queries that are executed
>>> 100's of times, you could still profit from preparing statements.
I gave a thought about this, and I am not sure prepared statements get
reused if a new instance of the prepared statement is created for
every execution. Do you have some knowledge on the subject? And in
jOOQ, are there ways to get the actual instance of the prepared
statement for external caching and APIs to reuse that instance for a
bind/fetch?
jTDS has some sort of internal caching for automatic reuse of
PreparedStatements, but it is unclear for me what are its criteria to
decide the reuse of a cached statement. Here is the place I had that
hint:
http://jtds.sourceforge.net/faq.html#preparedStatmentMemoryLeak
> Making the API thread-safe won't be a priority for jOOQ 2.x as it
> would mean major changes to the API itself.
Well, anyway, most JDBC objects are not thread safe so I don't know
what it would mean to have a thread safe jOOQ, especially when some
properties are located at the factory level and you want those
properties to apply to the current thread of execution. Having it not
thread safe is not a problem, I just wanted to clarify the situation.
Cheers,
-Christopher
