davenverse / fuuid Goto Github PK

FUUIDVar from fuuid-http4s provides support for extracting path params, but there's no support for extracting query params.

It would essentially be something like

implicit val fuuidQueryParamDecoder: QueryParamDecoder[FUUID] =
  QueryParamDecoder.fromUnsafeCast(v => FUUID.fromString(v.value).right.get)("FUUID")

and use

object UserIdQueryParamMatcher extends QueryParamDecoderMatcher[FUUID]("userId")

val routes: HttpRoutes[F] = HttpRoutes.of[F]({
  case req @ GET -> Root / "get" :? UserIdQueryParamMatcher(userId) =>
    for {
      result <- controller.get(userId)
      res <- result.map(Ok(_)).getOrElse(NotFound())
    } yield res
})

@ChristopherDavenport if you agree this is useful, I can send a PR.

Currently Either[IllegalArgumentException, FUUID] I think that do to a level of distrusting java's checked exception this should be broadened to Either[Throwable, FUUID]

I appreciate thoughts on this.

Http4s is a critical functional component and often people match on a path segment that is a UUID and would like to directly extract. We should provide such an extractor.

Doobie currently provides utilities to write and read values as UUID's in postgres. As Doobie is an important tool in functional programming community. We can provide a module which provides the Meta - Get/Put instances. So people can easily read and write these values.

Include custom mapper for FUUID to support integration with Slick.

Info: http://slick.lightbend.com/doc/3.2.3/userdefined.html

Fixed By #129

Please add FUUID.hashCode implementation for efficient usage in maps and sets

It is a small library without any dependencies: https://github.com/jchambers/fast-uuid

No 0.7.1 to be found, only 0.7.0
https://repo1.maven.org/maven2/io/chrisdavenport/fuuid_2.13/

FUUIDVar from the http4s module simply defines an unapply method, which is "standard" and not specific to http4s in any way.

Could it make sense to move that unapply into the core FUUID object so that one would get path extractors out of the box without the extra dependency?

import io.chrisdavenport.fuuid.FUUID

Path("/v1/16a30838-5e02-4e68-a1bc-585e42594430") match {
  case Root / "v1" / FUUID(uuid) => // do something with uuid
  case _ => // nope
}

I understand that conceptually the unapply method is there to support http4s extractors, but it could technically be useful in any other match clause regardless of https.
This is a result of the cool design of http4s' DSL, and it would be interesting to exploit it :)

The http4s module is still useful for http4s-specific things like #69

Regardless of the lameness of java serialization, there some frameworks and libraries that rely on it. (My current example is using FUUID in Apache Beam.)

It would be useful if FUUID declared itself java.io.Serializable, and likely delegated its serialization to the underlying UUID. I realize the implementation of this would be Unsafe, but that's mostly the nature of java serialization anyway I suppose.

I believe that these projects should offer a friendly and safe space for working together. I am in the process of adding this to most of my libraries.

If you have comments to this regard, I would like to hear them and this issue will be a good place to field such discussions.

I think the name based variant could have non-monadic return types?

Like postgres support, but for H2 database

scala> :paste
// Entering paste mode (ctrl-D to finish)

import java.util.UUID
UUID.fromString("2630147c-4a18-4866-9bbd-b2d89acef83z")

// Exiting paste mode, now interpreting.

java.lang.NumberFormatException: For input string: "b2d89acef83z"
  at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
  at java.lang.Long.parseLong(Long.java:589)
  at java.lang.Long.valueOf(Long.java:776)
  at java.lang.Long.decode(Long.java:928)
  at java.util.UUID.fromString(UUID.java:206)
  ... 44 elided

this makes the fromEither function impure

This functionality is also not available from java.util.UUID, but it is incredibly useful and is fairly straightforward to implement. If this seems like a good home for this, I'm glad to make a PR.

The code

import doobie.postgres.implicits._
import io.chrisdavenport.fuuid.doobie.implicits._

io.chrisdavenport.fuuid.doobie.implicits.FuuidMeta

causes

java.lang.StackOverflowError
  at io.chrisdavenport.fuuid.doobie.implicits$.FuuidMeta(implicits.scala:19)

Hi! It's seems like .show method is broken:

object FUUID {
  implicit val instancesFUUID: Hash[FUUID] with Order[FUUID] with Show[FUUID] = 
    new Hash[FUUID] with Order[FUUID] with Show[FUUID]{
      override def show(t: FUUID): String = t.show
...

it will fall to infinite recursion and end up with StackOverFlowError

They both extend Eq. Making a single Order with Hash fixes this issue I think.

Sorry for no test/PR but I’m on the phone.

Basic Encoder/Decoder instances for FUUID

In response to how many changes have been introduced releasing a release candidate first with an expected release date at the beginning of next week assuming no problems are found.