Enable SqlLogging by class/dao?

[chriskessel]

We have dozens of "Dao" classes for type specific lookups (e.g. query Users, Floobles, etc). I'd like to enable logging for one of them while I'm debugging something, but it looks like setSqlLogger() is universal.

Is there a way to be selective about what it logs?

[stevenschlansker]

Unfortunately I don't see a simple way to do this right now. If you have access to the Handle, you can call getExtensionMethod(), but you do not have access to that in the SqlLogger interface. We could add a getExtensionMethod() to the StatementContext object you are passed - then the logger could see which class and method were called. Would that solve your problem?

[chriskessel]

The context has a getExtensionMethod() on it. I'm using it to help augment my log line so I can grep for the class of interest.

Works for local debugging, but would break down a bit in prod with just too much spew. It be useful to say "log everything from the NewFeatureThingExtension", but not log all the other extensions. Not sure what that looks like, a logger per extension somehow? A per extension annotation that says whether it should get logged?

Food for thought anyway.

[stevenschlansker]

Oh, you're entirely right, how did I miss that!

To implement that, can't you implement a logger that checks the extension class?

void logAfterExecution(StatementContext context) {
    if (context.getExtensionMethod().getType() == NewFeatureThingExtension.class) {
        .... log
    }
}

[chriskessel]

Yep, I can add a chunk of code to specifically look as you mentioned. Maybe I can extend that concept to look at a sql_logging.yml config or something so I can enable/disable outside of the code itself.

[stevenschlansker]

Yeah, we don't ship anything like this out of the box, but if you build something that is both generally applicable and small and self-contained, we'd be happy to consider it for inclusion :)

[stevenschlansker]

I'll close this as answered - right now you have to write code to accomplish this. If there's desire for a more configuration-forward way to do it, we'd be happy to consider contributions to that effect. Thanks for the question!

[stevenschlansker]

Oh, I didn't realize the driver could do that.
The StatementContext also provides direct access to the PreparedStatement via getStatement - does that do what you want?

[chriskessel]

I was just going there :). Yes, that lets me get to the PreparedStatement! Sadly, in our environment it's one that wraps the actual Postgres one, so I'm digging into that. But that's a me issue, not a JDBI issue.

So, the good news for anyone that finds this by Google search and uses a normal library (e.g. Hikari) with Postgres, you should be able to log the actual SQL with context.getStatement().toString(). Hurray!

Thanks for your help on this, it definitely helped guide me in poking around in the guts.

[stevenschlansker]

If your wrapper implements the java.sql.Wrapper interface, you might be able to statementContext.getStatement().unwrap(PgStatement.class).toString(), although it is not guaranteed to help, depending on exactly how the wrapper works.

[chriskessel]

Sweet, that works!

[stevenschlansker]

Awesome!