-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use UUIDGen
instead of randomUUID()
#678
Conversation
.jsSettings( | ||
// https://www.scala-js.org/news/2022/04/04/announcing-scalajs-1.10.0#fixes-with-compatibility-concerns | ||
libraryDependencies += ("org.scala-js" %%% "scalajs-java-securerandom" % "1.0.0") | ||
.cross(CrossVersion.for3Use2_13) | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although in theory this dependency is secure, in practice it is not safe to rely on. See discussion in:
@@ -52,12 +53,26 @@ object PagingSelfAwareStructuredLogger { | |||
* @return | |||
* SelfAwareStructuredLogger with pagination. | |||
*/ | |||
def withPaging[F[_]: Monad](pageSizeK: Int = 64, maxPageNeeded: Int = 999)( | |||
def withPaging2[F[_]: Monad: UUIDGen](pageSizeK: Int = 64, maxPageNeeded: Int = 999)( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I wasn't feeling creative with naming at this moment 😅 I will happily change this to any suggestion, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should name it paged
? 🤔 and just keep that as the future API
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works for me! :)
new PagingSelfAwareStructuredLogger[F]( | ||
pageSizeK, | ||
maxPageNeeded, | ||
Monad[F].unit.map(_ => UUID.randomUUID()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Terrible, right! But this just more clearly exposes the bad behavior that already existed here. There is no safe way to generate random UUID
s with only a Monad
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Absolutely! I'm just sorry I didn't catch it before
LGTM! I'm fine with merging this. Leaving it open for other maintainers to weigh in. |
@@ -46,18 +46,14 @@ lazy val core = crossProject(JSPlatform, JVMPlatform) | |||
.settings( | |||
name := "log4cats-core", | |||
libraryDependencies ++= Seq( | |||
"org.typelevel" %%% "cats-core" % catsV | |||
"org.typelevel" %%% "cats-core" % catsV, | |||
"org.typelevel" %%% "cats-effect-std" % catsEffectV |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to keep the initial goal of having the core module CE-less, can we introduce an internal interface for UUIDGen and its implementation within the slf4j module?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we instead create a new module that is explicitely dependent on CE? And move the correct version of this there?
I feel like re-defining a UUIDGen equivalent leads to a lot of confusion and bad UX. Instead, having a log4cats-core
package that is honest about its limitations, and an extension logs4cats-ce
(naming is hard) that overcomes aforementioned limitations might be better.
Although not entirely sure how to pull this off in a bincompat and user friendly way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, adding a "log4cats-effect
" would be better for UX, but still not great for UX+bincompat.
Just so that we are clear: what are the arguments against just have a CE dependency in the core module?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what are the arguments against just have a CE dependency in the core module?
Very good question! I personally don't know since I probably missed those discussions during my absence. 🙈 Personally I think it's ok to have CE in core
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can only guess, but perhaps the reason is to apply the Rule of Least Power. But once again, I'm not sure if this is a thing still.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say it is a thing still :) The problem is the repo is currently applying the principle of too-little-power. This is a course-correction.
@danicheg so wdyt, can we move forward with adding CE to core? If not, my best suggestion is to:
|
To sum up my thoughts: |
I spoke with @ChristopherDavenport on Discord. Here's a quick summary: Regarding CE in core:
Regarding UUIDs:
So it boils down to a question of UX:
Thoughts? @danicheg thanks again for raising this issue, it's opened some good questions. |
It comes that all of us don't mind adding the CE std module to the log4cats core. So let's move onward with this. 👍 from me to that. |
Fixes #677.