This is now implemented for jOOQ 3.3.0. It won't be merged to 3.2.x,
because the optimal implementation is a bit too complex for a patch.
Instead of coupling bind variables (org.jooq.impl.Val) with the semantics
of the logger by adding additional flags / settings, I chose to
implement a *VisitListener
*to fully transform the SQL statement in case we're DEBUG logging. This is
only done at DEBUG level, not at TRACE level, when all bind variables are
logged in full. In addition to replacing these bind values, an additional
comment is rendered at the end of the SQL statement to indicate that the
log entry has abbreviated values in it.
Here's the current implementation, which nicely shows the workings of such
a VisitListener. It replaces bind values when they're String or byte[] and
longer than maxLength. This example will also help promote this
killer-feature of jOOQ, I hope.
private static class BindValueAbbreviator extends DefaultVisitListener {
private boolean anyAbbreviations = false;
@Override
public void visitStart(VisitContext context) {
if (context.renderContext() != null) {
QueryPart part = context.queryPart();
if (part instanceof Param<?>) {
Param<?> param = (Param<?>) part;
Object value = param.getValue();
if (value instanceof String && ((String)
value).length() > maxLength) {
anyAbbreviations = true;
context.queryPart(val(abbreviate((String) value,
maxLength)));
}
else if (value instanceof byte[] && ((byte[])
value).length > maxLength) {
anyAbbreviations = true;
context.queryPart(val(Arrays.copyOf((byte[])
value, maxLength)));
}
}
}
}
@Override
public void visitEnd(VisitContext context) {
if (anyAbbreviations) {
if (context.queryParts().length == 1) {
context.renderContext().sql(" -- Bind values may have
been abbreviated for DEBUG logging. Use TRACE logging for very large
bind variables.");
}
}
}}
2014-01-10 Lukas Eder <[email protected]>:
> Hi Darren,
>
> This is indeed a bit unfortunate, thanks for reporting. I think the
> default implementation should be fixed, preventing excessive logging in the
> event of LOB (or VARCHAR) content. This should be easy to fix through a
> couple of adaptations to the renderers. I have registered #2939 for this:
> https://github.com/jOOQ/jOOQ/issues/2939
>
> This fix will probably also be merged to jOOQ 3.2.3
>
> Cheers
> Lukas
>
>
> 2014/1/8 Darren S <[email protected]>
>
>> First off, let me say I love the logging in jOOQ, very useful. But I've
>> hit a bit of problem. The issue I have is that when the variables are
>> bound, for one specific query I have, the SQL is too long. It ends up
>> printing megabytes of content (it has a MySQL MEDIUMTEXT field in it).
>> This in turn ends up crashing the Eclipse console view.
>>
>> So what I've done is extended the LoggerListener.renderEnd() and put in
>> logic to not print the bind variable text if its longer than a certain
>> number of characters. I then disable execution logging and add my own
>> ExecuteListeners. Now this is working basically fine. What I was wonder
>> is if there is a better way to do this? I was thinking maybe two different
>> approaches.
>>
>> 1) During the rendering of the SQL, somehow limit the bound variables
>> text to a certain width
>> 2) Log the bind SQL text to a different logger and then use logback to
>> limit the message width "%.100m"
>>
>> Thoughts?
>>
>> Darren
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "jOOQ User Group" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
--
You received this message because you are subscribed to the Google Groups "jOOQ
User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
