Hi Christopher, > I think I saw somewhere on the documentation that we could get some > details on the SQL requests that get through by increasing the logging > level (debug, trace). > Unless I am mistaken, this is currently all there is to monitor what > is happening.
I don't think that I put it in the manual. But it can be found on Stack Overflow or my blog: http://stackoverflow.com/questions/8561317/how-can-we-profile-jooq-statements-for-speed http://lukaseder.wordpress.com/2011/10/20/debug-logging-sql-with-jooq/ Yes, that's currently the only means of tracing SQL / JDBC activities > Let me explain: > [...] > Any kinds of listeners can be implemented and added/removed at any > time: console output, scripts, GUI. That sounds like a very interesting tool that you made! Short of Oracle Grid Control or something like Dynatrace, it can be quite handy to directly introspect SQL artefacts and performance like that. > So, are there such capabilities in jOOQ that I overlooked? If not, are > there any plans on adding such API (possible due to jOOQ being a > centralised access)? Not as of right now. This had been requested once before, but I had forgotten about it: https://groups.google.com/d/topic/jooq-user/dScAOIdyZLI/discussion I think the other request went quite far, also asking for means to patch the queries being executed. In any case, I think the time is ripe to put this on the feature roadmap. Now that I'm adding runtime configuration to the Factory, I don't see why this shouldn't be implemented: https://sourceforge.net/apps/trac/jooq/ticket/1157 Let's summarise. In essence both you - and at the time Vladislav Rastrusny - are asking for a simple listener API that is invoked by jOOQ every time jOOQ performs some JDBC operation. To make things more concise, this API is implemented by default by the existing JooqLogger. But you can also add more listeners to the API that implement custom tracing behaviour. Probably, this is best implemented using the new runtime configuration that I'm adding for jOOQ 2.0.5. To every Factory, you can add a list of classes that jOOQ should initialise and make calls to. The interesting info is: - SQL with inlined values for debugging - SQL as rendered to the PreparedStatement / Statement - The org.jooq.Query object - The org.jooq.Configuration object Also, the callback should be allowed to provide wrappers for: - JDBC Connection - JDBC Statement - JDBC PreparedStatement - JDBC CallableStatement - JDBC ResultSet And it should be notified of these events: - Preparing the statement - Binding of each variable - Execution of the statement - Fetching of each row / value This new API could also be merged with some existing functionality that was originally requested by Sander Plas (although that is secondary): http://www.jooq.org/manual/JOOQ/Serializability/ Am I missing something, yet? Cheers Lukas
