When the code for executing queries was implemented for the new custom ORM, support for logging the executed queries to a
SQLStatementLogger) was also added. This tool was created mostly for helping compare the queries created by Hibernate with the queries generated by
The class is implemented as a singleton, so, to add an event the following construct is used:
It is configurable, much like Hibernate was (using registry keys
"persistence/enable-sql-logging" globally and
"database/" + database.getName() + "/orm/show_sql" per database). More than that, each database can have a specific stream assigned, so queries for each database can be channelled to a different file. Each such stream can have an optional, customized timestamp date format, and the logs for each database can be independently activated and deactivated at will:
SQLStatementLogger.getLogger().setStream(<database>, <stream>); SQLStatementLogger.getLogger().setEnabled(<database>, true/false); SQLStatementLogger.getLogger().setTimestamp(true/false, <date-format>);
OTOH, during the optimization phase some other tool was added which kept track of multiple pieces of code, timed their execution is printed to
System.err a short report of the number of invocations, the average and maximum time took by a single call. The class name is
OperationTimer and can be found only in sub-branch 4397a merged into 3821c, starting with revision: 11967.1.2. This is not a query-specific tool, instead it can time any block of code.
Since the goal of these tools were in-house optimizations, they have some javadoc class and method attached, but not very well documented. Unfortunately, none of them does have a threshold trigger, yet. Of course,
SQLStatementLogger can be easily enhanced with an optional threshold value whose meaning is to filter out fast queries and expose only those which slows down the application.