Allow for different effects of HikariTransactor and its creation

[sideeffffect]

/cc @piton4k
closes #1902

[jatcwang]

This is related to #1902 is that right?

[sideeffffect]

Oh yes, it is 👍
/cc @lgmyrek

[sideeffffect]

@jatcwang 🙏

[jatcwang]

Sorry for the delay. I'm planning to playing around with the provided scenarios (from the issue) to get a better understanding of the need.
A nitpick for now is that Resource[M, HikariTransactor[N]] is ideally Resource[N, HikariTransactor[M]] as most people are used to seeing Transactor[M].

[satorg]

May I add my two cents on this please. I wonder if it was better to create a separate set of functions with two effects instead of introducing breaking changes to the existing ones. Then the existing function could be kept compatible but their implementation could be changed to call the new more generic functions. The reasoning is that I guess likely 90-95% users (or so) do not need the effect separation. I believe it is a good practice in general – to provide simplified functions/methods for most common usages.

[jatcwang]

Yes I agree that'd be great @satorg :)

[sideeffffect]

most people are used to seeing Transactor[M]

Good idea! I've renamed the other type variable to M0.

provide simplified functions/methods for most common usages

It's not worth it. You can always just write

HikariTransactor.fromHikariConfig[IO, IO](hikariConfig)

instead of fromHikariConfig[IO]. It's a trivial change (that you typically need to make just once in your app). Duplicating all the functions just isn't worth the small benefit this would bring.

[satorg]

It's a trivial change (that you typically need to make just once in your app). Duplicating all the functions just isn't worth the small benefit this would bring.

I totally agree that it is not that big deal. However, on the flip side changing existing functions
a. introduces a breaking change urging everyone to take an action upon the next upgrade;
b. introduces the new syntax which the majority of users do not care about.

Needless to say that adding a couple of new functions to the library is not a big deal either. No code duplication necessary there – more common used functions can simply call to more generic but relatively rare used ones. In other words: either do it just once in the library and that's it versus everyone does just once but in each project that uses the library.

That said, I realize that it is absolutely matter of perception which of the two sides outweighs.

[sideeffffect]

No code duplication necessary there

Unfortunately it is a lot of code duplication. Majority of the code would be the long function signatures (which you can't reuse in contrast to function bodies). We're in an RC phase, we can afford changes like these.

Of course, if we were stable already, I'd go with the worse, but compatible, way of duplicating the code.

[jatcwang]

I'm in general agreement with @satorg here. It's best to uphold backwards compatibility and user-friendliness unless our hands are forced.

But I can do the suggested change in a follow-up PR, no problem.

[sideeffffect]

I'm afraid that duplicating each method (once with 1 type parameter, once with 2 type parameters) would not be a nice API and very user friendly.

But if that's what you want, I can do that myself. I think I'll have time to do it sometime this week.