lykahb / groundhog

This library maps datatypes to a relational model, in a way similar to what ORM libraries do in OOP. See the tutorial https://www.schoolofhaskell.com/user/lykahb/groundhog for introduction
http://hackage.haskell.org/package/groundhog
176 stars 39 forks source link

Record fields with underscores give TH machinery trouble #29

Open ozataman opened 10 years ago

ozataman commented 10 years ago

The below yields a large error complaining about:

    Illegal data constructor"
<- " name: `_pgHostField'
    When splicing a TH declaration:
      instance Database.Groundhog.Core.PersistEntity Compute.Backends.PGCommon.PGConfig
    where data Database.Groundhog.Core.Key Compute.Backends.PGCommon.PGConfig

Example code:

data PGConfig = PGConfig
    { _pgHost     :: Text
    , _pgPort     :: Int
    , _pgUser     :: Text
    , _pgPass     :: Text
    , _pgDatabase :: Text
    , _pgSchema   :: Text
    , _pgSSL      :: SSLMode
    } deriving (Eq,Show,Generic)
- entity: PGConfig
  dbName: xxxxx
  constructors:
    - name: PGConfig
lykahb commented 10 years ago

The naming schema tried to create a field (GADT constructor) pgHostField which is an invalid constructor name. I would suggest modifying the naming schema. There are many ways to make the name valid (strip , add prefix) but putting these heuristics into the default schemas I think would make the library more "magical"

ozataman commented 10 years ago

Understood. However, we may want to expose some functionality that provides this prefix stripping, especially as lens becomes more and more prevalent and field names starting with are the norm there.

lykahb commented 10 years ago

Good point. My comment was about names normalization in general. If this is a common case, a NamingStyle adjustment function would be handy. Do you think that stripping underscores is the best option here?

ozataman commented 10 years ago

I guess so. It is not at all idiomatic to use underscores in general, so perhaps we can assume they are safe to strip. If someone has a special use case, they can always implement their own naming schema, right?

lykahb commented 10 years ago

That's right. I am not sure though if this case is popular enough to be included into the TH module. Otherwise you could use this schema modification just for your own project.

yaitskov commented 4 years ago

Workaround:

mkPersist
  (defaultCodegenConfig
   {  namingStyle = lowerCaseSuffixNamingStyle {
                      mkExprSelectorName =
                        \a b c d -> "Z" ++ (mkExprSelectorName lowerCaseSuffixNamingStyle) a b c d
                      }
   })
   [groundhog|
   ...