No builtin support for UUID

[pseudonom]

Should support for UUIDs be built in to persistent or should it be its own package? FYI, the own package version might look something like

{-# OPTIONS_GHC -fno-warn-orphans #-}

module Instances where

import Control.Error.Util
import Data.UUID (UUID)
import qualified Data.UUID as UUID
import qualified Data.ByteString.Lazy as BSL
import Database.Persist.Sql
import Web.HttpApiData

instance PersistField UUID where
  toPersistValue = PersistDbSpecific . BSL.toStrict . UUID.toByteString
  fromPersistValue (PersistDbSpecific t) =
    case UUID.fromByteString $ BSL.fromStrict t of
      Just x  -> Right x
      Nothing -> Left "Invalid UUID"
  fromPersistValue _ = Left "Not PersistDBSpecific"
instance PersistFieldSql UUID where
  sqlType _ = SqlOther "uuid"
instance PathPiece UUID where
  toPathPiece = toUrlPiece
  fromPathPiece = hush . parseUrlPiece
instance ToHttpApiData UUID where
  toUrlPiece = UUID.toText
instance FromHttpApiData UUID where
  parseUrlPiece uuid = note ("Error parsing UUID " <> uuid) . UUID.fromText $ uuid
instance ToJSON UUID where
  toJSON = toJSON . UUID.toText
instance FromJSON UUID where
  parseJSON uuid = maybe (fail $ "Error parsing UUID " <> show uuid) pure . UUID.fromText <=< parseJSON $ uuid

[gregwebs]

I think it should be added.

• it's lightweight
• uuid is an important (even if overused) data type for databases

Want to send A pr?

[bergey]

I'd like to work on this over the next couple of weeks. Is the approach shown above good by the maintainers, or would you hold out for a solution that supports more backends? I'm only familiar with Postgres, so I will need some help if folks want the more general solution.

Incidentally, the HTTP & JSON instances have been added upstream, so only the 2 Persist instances are needed now.

[MaxGabriel]

I'm good with this approach. This is what we're using at work right now if you want to base it off that:

--------------------------------------------------------------------------------
instance PersistField UUID where
  toPersistValue = PersistDbSpecific . toASCIIBytes
  fromPersistValue (PersistDbSpecific uuid) =
    case fromASCIIBytes uuid of
      Nothing -> Left $ "Model/CustomTypes.hs: Failed to deserialize a UUID; received: " <> T.pack (show uuid)
      Just uuid' -> Right uuid'
  fromPersistValue x = Left $ "Model/CustomTypes.hs: When trying to deserialize a UUID: expected PersistDbSpecific, received: " <> T.pack (show x)

instance PersistFieldSql UUID where
  sqlType _ = SqlOther "uuid"

instance PathPiece UUID where
  toPathPiece = toText
  fromPathPiece = fromText

I think these instances should be added to the persistent-postgresql package, since they're specific to that backend. It looks like if we e.g. added one for MySQL, we'd want to strip the hyphens and store it as binary (just based off some googling), and SQLite I think a BLOB. If you'd like you can add instances for the other backends in the other packages, but it isn't required.

Can you add a test for this as well?

[Vlix]

Isn't this in persistent right now? If not, I'm confusing it with our production code. Shouldn't be too difficult to implement, right? If it isn't already, I might pick this up in the near future.

[tdxiong]

Isn't this in persistent right now? If not, I'm confusing it with our production code. Shouldn't be too difficult to implement, right? If it isn't already, I might pick this up in the near future.

I am using lts-14.6, postgresql 11 on windows 10, no need to import Data.UUID, just create extension "uuid-ossp" for your database, the in your model, do

Id Text default=uuid_generate_v4()

postgresql will generate an uuid primary key for you, no need extra instance

[jezen]

@tdxiong It's arguably preferable though to use a real UUID type, rather than a Text type which incidentally happens to contain a UUID value.

We use model definitions like this

User sql=users
  Id UUID default=uuid_generate_v4()
  ...

You could even take this further and create newtype wrappers for UUIDs for each different kind of model. It's generally a code-smell to stringly-type everything.

[tdxiong]

noted.

On a side note, current UUID implementations are actually not good as UUID can't be Lexicographically Sortable. There is a unofficial v6 version of addressing the issue, also there are solutions like ulid, cuid, etc.

[jezen]

@tdxiong Thanks for that note. It's not something I had considered, though at least in our case it is not important for us to sort on a primary key; we sort on some other UTCTime field. It may indeed be important for some people to have sortable keys.

[tysonzero]

@MaxGabriel

It seems weird to me that it's sent back from the DB as an ascii string, why wouldn't it give back a 16 byte bytestring?

Adding the instance in persistent-postgresql seems impossible, as then if you added it in persistent-mysql as well you would have overlapping instances. I think we have to find a way to support as many platforms as possible with a single instance.

@bergey

What is the status on this?

[parsonsmatt]

Unfortunately postgresql and mysql differ on UUID represnetation. From this post it appears that mysql represents a UUID as a varchar(36), while postgres has it's own uuid type.

mysql does not have a way for users to create their own datatypes, so you can't even tell MySQL that it should interpret uuid as a varchar(36) alias. Nice.

I don't want to make MySQL's bad decisions a problem for Postgres users, but I'm also hesitant on providing "Official" support to a non-standard extension.

I suggest that we have a module Database.Persist.Postgresql.UUID that contains a newtype PgUUID = PgUUID UUID and has the right instances defined.

[tysonzero]

I get where you are coming from. Although I can't think of a more reasonable instance than the PostgreSQL one, so personally I'd prefer to choose that one rather than have no instance at all. Then for incompatible backends you can use a newtype.

Ideally we would be able to have different instances/behavior for different backends. Although the complexity and boilerplate may not be worth it.