Hello, > We actually use jTDS. My sense is that to avoid the round-trip means > having special communication protocol with the server. If that were > present in SQLServer, then the SQLServer standard driver would make > use of it.
That makes sense >> Note that getSQL() renders bind variables as "?". What you would need >> is Factory.renderInlined(QueryPart). > > Thanks for the tip. Wouldn't the API look cleaner from a usage point > of view if we had a direct method like the "getSQL" one rather than > having to go through the Factory? So far, inlined SQL was only used for DEBUG logging. I wasn't aware of any users using this for execution. Hence the lack of "convenient" API support. But of course, you're right. I'll add some method to org.jooq.Query, probably overloading getSQL() with a boolean flag: https://sourceforge.net/apps/trac/jooq/ticket/1146 > Out of curiosity, how do you inline certain complex types like doubles or > dates? Doubles (any java.lang.Numbers) are easy to inline. Just use toString(). Maybe there are 1-2 issues with the correct scale/precision when inlining BigDecimal. 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): https://github.com/lukaseder/jOOQ/blob/7129865aebd9fe3580180d9ddaab41e441420678/jOOQ/src/main/java/org/jooq/impl/Val.java#L248 Obviously, this has to be reviewed when inlined bind variables should be used in executable SQL. I'll add a ticket as a reminder to add appropriate integration tests, also for byte[] and arrays/udts: https://sourceforge.net/apps/trac/jooq/ticket/1147 >> 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. > > Does it mean I have to create one factory per thread? In fact, how is > jOOQ with regards to multi threading? Are some objects multithreaded? jOOQ's Factory and most artefacts created from it are not thread-safe. This is also documented in the Factory http://www.jooq.org/javadoc/latest/org/jooq/impl/Factory.html Making the API thread-safe won't be a priority for jOOQ 2.x as it would mean major changes to the API itself. > Again: do cross check my claims! I wouldn't want you to spoil your API > with unneeded features. Runtime-configuration has been on the roadmap for a long time. This seems to be a good time to start implementing it. I'll keep the roadmap in mind when adding this first configuration item. It won't spoil the API, don't worry :-) But in any case, I do believe that sometimes also with Oracle databases, it's useful to explicitly force hard-parses by inlining bind values. In some corner-cases, that can heavily outperform using bind values when the pre-existing execution plans are off. I've spent quite some time debugging bind-value peeking issues in Oracle. Some examples: - http://stackoverflow.com/questions/5353810/how-to-inline-a-variable-in-pl-sql - http://stackoverflow.com/questions/6956025/use-oracle-unnested-varrays-instead-of-in-operator So other people will benefit from this enhancement as well. Cheers Lukas
