Closed andremarianiello closed 2 years ago
These things are merely the underlying details of this library. Exposing them would mean making them a part of its essential API, which they never were intended to be. So I suggest to simply reimplement them in your project.
I also don't think that reusing the isolation level and mode types would help the interoperability much, but adding a dependency on hasql-transaction will add a maintenance burden for you in case there'll be an API-breaking change released for hasql-transaction.
Do you feel the same way about the idea of pulling them into their own library? e.g. hasql-transaction-core
Regardless of library separation, exposing things is always about the balance between the maintenance burden and the achieved value.
If we were to compare exposing the discussed things as part of "hasql-transaction" vs "hasql-transaction-core" I would strongly vote for the second option. However I just don't see much value in sharing the discussed things compared to the maintenance burden that it would bring above all.
I am open to be convinced otherwise though. Why do you feel you need that as much?
No worries, I'm not looking to convince you! These are just options I had thought of but cannot evaluate accurately because of my lack of experience in this space. I am happy enough to duplicate the logic in my own library for now and reevaluate the choice periodically going forward. Thanks for your time and for the advice!
As I mentioned in here I am working on another type to represent transactions. To help with interoperability I am reusing the IsolationLevel and Mode types from hasql-transaction. Additionally, I could make use of the beginTransaction, commitTransaction, and abortTransaction statements from Hasql.Transaction.Private.Statements, if you were willing to expose them. If not I could always make my own version of course, but I thought it was worth asking. If you don't mind them being exposed but don't want to make the change I could do that as well.