public class DefaultDiagnosticsListener extends Object implements DiagnosticsListener
DiagnosticsListener.
Use this to stay compatible with future API changes (i.e. added methods to
DiagnosticsListener)
| Constructor and Description |
|---|
DefaultDiagnosticsListener() |
| Modifier and Type | Method and Description |
|---|---|
void |
duplicateStatements(DiagnosticsContext ctx)
The executed JDBC statement has duplicates.
|
void |
missingWasNullCall(DiagnosticsContext ctx)
The fetched JDBC
ResultSet returned a primitive type value for a
column, which could have been null, but ResultSet.wasNull() was
not called. |
void |
repeatedStatements(DiagnosticsContext ctx)
The executed JDBC statement is repeated consecutively on the same JDBC
Connection. |
void |
tooManyColumnsFetched(DiagnosticsContext ctx)
The fetched JDBC
ResultSet returned more columns than necessary. |
void |
tooManyRowsFetched(DiagnosticsContext ctx)
The fetched JDBC
ResultSet returned more rows than necessary. |
void |
unnecessaryWasNullCall(DiagnosticsContext ctx)
The fetched JDBC
ResultSet returned a value for a column, on
which ResultSet.wasNull() was called unnecessarily (more than
once, or for a non-primitive type). |
public void tooManyRowsFetched(DiagnosticsContext ctx)
DiagnosticsListenerResultSet returned more rows than necessary.
An event indicating that a JDBC ResultSet was fetched with
A rows, but only B rows (B < A)
were consumed.
Typically, this problem can be remedied by applying the appropriate
LIMIT clause in SQL, or SelectLimitStep.limit(int)
clause in jOOQ.
tooManyRowsFetched in interface DiagnosticsListenerpublic void tooManyColumnsFetched(DiagnosticsContext ctx)
DiagnosticsListenerResultSet returned more columns than necessary.
An event indicating that a JDBC ResultSet was fetched with
A columns, but only B (B < A)
were consumed.
Typically, this problem can be remedied by not running a
SELECT * query when this isn't strictly required.
tooManyColumnsFetched in interface DiagnosticsListenerpublic void unnecessaryWasNullCall(DiagnosticsContext ctx)
DiagnosticsListenerResultSet returned a value for a column, on
which ResultSet.wasNull() was called unnecessarily (more than
once, or for a non-primitive type).unnecessaryWasNullCall in interface DiagnosticsListenerpublic void missingWasNullCall(DiagnosticsContext ctx)
DiagnosticsListenerResultSet returned a primitive type value for a
column, which could have been null, but ResultSet.wasNull() was
not called.missingWasNullCall in interface DiagnosticsListenerpublic void duplicateStatements(DiagnosticsContext ctx)
DiagnosticsListenerMany databases maintain an execution plan cache, which remembers execution plans for a given SQL string. These caches often use the verbatim SQL string (or a hash thereof) as a key, meaning that "similar" but not identical statements will produce different keys. This may be desired in rare cases when querying skewed data, as a hack to force the optimiser to calculate a new plan for a given "similar" but not identical query, but mostly, this is not desirable as calculating execution plans can turn out to be expensive.
Examples of such duplicate statements include:
SELECT * FROM actor;
SELECT * FROM actor;
SELECT * FROM actor WHERE id = 1;
SELECT * FROM actor WHERE id = 2;
SELECT a1.* FROM actor a1 WHERE id = ?;
SELECT * FROM actor a2 WHERE a2.id = ?;
Examples of identical statements (which are not considered duplicate, but
DiagnosticsListener.repeatedStatements(DiagnosticsContext), if on the same
Connection) are:
SELECT * FROM actor WHERE id = ?;
SELECT * FROM actor WHERE id = ?;
This is a system-wide diagnostic that is not specific to individual
Connection instances.
duplicateStatements in interface DiagnosticsListenerpublic void repeatedStatements(DiagnosticsContext ctx)
DiagnosticsListenerConnection.
This problem goes by many names, the most famous one being the N + 1 problem, when a single (1) query for a parent entity requires many (N) subsequent queries for child entities. This could have been prevented by rewriting the parent query to use a JOIN. If such a rewrite is not possible (or not easy), the subsequent N queries could at least profit (depending on the exact query):
PreparedStatement
This problem can be aggravated if combined with the
DiagnosticsListener.duplicateStatements(DiagnosticsContext) problem, in case of
which the repeated statements might not be diagnosed as easily.
Repeated statements may or may not be "identical". In the following
example, there are two repeated and identical statements:
SELECT * FROM actor WHERE id = ?;
SELECT * FROM actor WHERE id = ?;
In this example, we have three repeated statements, only some of which
are also identical:
SELECT * FROM actor WHERE id = ?;
SELECT * FROM actor WHERE id = ?;
SELECT * FROM actor WHERE id = ?;
This is a Connection-specific diagnostic that is reset every time
Connection.close() is called.
repeatedStatements in interface DiagnosticsListenerCopyright © 2019. All rights reserved.