Doobe Psql module integration

[jbwheatley]

Very similar issue to #227 . If you use DoobieEnum with postgres enum types, you get errors like:
"org.postgresql.util.PSQLException: ERROR: column "shirt" is of type shirtsize but expression is of type character varying"

In order to work with postgres enums in doobie, you need to provide the name of the type you have created. E.g. if you have CREATE TYPE shirt_size AS ENUM ('small', 'medium', 'large');, then you need to create a doobie meta instance like so: implicit val meta: Meta[ShirtSize] = pgEnumString("shirt_size", withName(_), _.entryName).

If enumeratum-doobie was going to include such an instance for the user, you would probably have to add def enumTypeName: String as an implementation detail for the user in DoobieEnum. Maybe instead a new mixin called DoobieStrictEnum could be added that provides this functionality? Happy to work on a PR for this and add a section to the readme, if there is interest for this.

[lloydmeta]

Hey, that sounds reasonable to me.

To double check my understanding: the current issue is that the enum in the doobie module basically only supports going to-and-from strings, but not Postgres custom enum types.

https://github.com/lloydmeta/enumeratum/blob/master/enumeratum-doobie/src/main/scala/enumeratum/Doobie.scala#L12

Your proposal is to add the ability to support custom enum types by giving the user a way of specifying the enum type when declaring the enum type (in scala land)

I think your suggestion makes sense; can give an example of how that would look in actual usage? Just want to double check that it feels right 🙂

[jbwheatley]

sure it would be something like:

trait DoobieStrictEnum[A <: EnumEntry] { this: Enum[A] =>
  def pgEnumTypeName: String
  implicit def meta: Meta[A] = pgEnumString(pgEnumTypeName, this.withName(_), _.entryName)
}

then user implementation would be like:

sealed trait ShirtSize extends EnumEntry

object ShirtSize extends Enum[ShirtSize] with DoobieStrictEnum[ShirtSize] {
  //all your case objects here
  val pgEnumTypeName: String = "shirt_size"
}

the name DoobieStrictEnum isn't necessarily the best, I'll think about that.

[lloydmeta]

That looks reasonable to me.

However, I just realised that we're talking about Postgres enums, and the Doobie integration we have so far, enumeratum-doobie, is not Postgres-specific, and I don't think it would make sense to force it to depend on the doobie Postgres module.

There are a few paths forward:

1. Add a section in the readme to document this current idea so people who need to use the Postgres module can easily define the mix in themselves
2. You can publish your own enumeratum-doobie-postgres module
3. We add a enumeratum-doobie-postgres module to this repo and I maintain and publish it

Quite candidly, at the moment, I don't really have much capacity nor desire to support (3) given the large number of existing modules. What are your thoughts on (1) and (2)?

[jbwheatley]

Actually I came to the same realization yesterday when I started having a closer look at this 😁

I don't think (2) is that worthwhile unless there was substantially more that could be pulled out into its own package - its really only 2 lines.

I think (1) is fine. I'll submit a PR to update the readme.

[satorg]

Hi guys. Just curious – any progress on this issue? I also faced this issue in my project some time ago and came up with a similar solution eventually. But it would be nice if I could use some common solution instead of our custom one.

[lloydmeta]

Hi guys. Just curious – any progress on this issue? I also faced this issue in my project some time ago and came up with a similar solution eventually. But it would be nice if I could use some common solution instead of our custom one.

At this point, the issue is to add a section to the readme to document the Doobie + Psql mix in. There are no plans to add a Psql-specific integration, if that's your question.