Using Doobie version >= 1.0.0-RC3 causes java.lang.NoSuchMethodError about tranzactio HOT 4 CLOSED

I've looked into updating doobie to 1.0.0-RC4 and have a branch where things compile BUT: the KleisliInterpreter now requires a LogHandler instance as a parameter which poses a challenge. I have a few ideas how to solve this but none of them are ideal:

• Just use LogHandler.noop => this is bad because query logging will be disabled which would break peoples expectations at runtime
• Update the api to take a LogHandler in connectionFromJdbc (and fromConnectionSource) => this is bad for multiple reasons. It's a breaking change and more importantly it would leak doobie specific details into the api (and would make this PR impossible: #45)
• Update io.github.gaelrenoux.tranzactio.doobie.Database to be a class that takes a LogHandler instance in the constructor => this is a breaking api change but it's the most flexible solution I can think of
• Create a custom LogHandler instance inside io.github.gaelrenoux.tranzactio.doobie.Database => this is bad because it would remove the option of customizing the LogHandler by users of this library but this is the least intrusive change(other than using LogHandler.noop) and might be a good temporary solution until the final doobie-1.0.0 is released(because things might change again while it's in RC).

What do you think @gaelrenoux ? I'd be happy to submit a PR if we can agree on a direction to take.

from tranzactio.

I just encountered this. We needed to upgrade doobie for effectful logging. @gaelrenoux, is there anything you need to move this forward? Would be happy to send a PR (if @erdeszt doesn't beat me to it first :))

from tranzactio.

A custom LogHandler is indeed the easiest solution. Honestly I think I'd use the noop in that case, rather that force logging of queries through a custom-built LogHandler instance: it's not perfect, but there are other ways to see the queries being executed, and forcing the logs would have performance implications. Obviously, that's still not a very good solution.

Changing the Database to to take a LogHandler instance on creation: I don't think that would work. All the layer-building methods (such as DatabaseModuleBase.fromDatasourceAndErrorStrategies`) wouldn't work without passing the LogHandler, which would again require changing the general API.

The best idea I can think of is to introduce a general Context trait, passed on creation, which would have a different implementation based on which library you are using. The Doobie implementation of Context would contain the LogHandler. This would also be a more flexible solution, that will allow other library-specific information to be carried when necessary. I'll try and see what I can do.

from tranzactio.

I've created PR #48 for this topic. I'd gladly have one of you guys review it, see what you think.

from tranzactio.