Skip to content
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

Record fields with underscores give TH machinery trouble #29

Open
ozataman opened this issue May 15, 2014 · 6 comments
Open

Record fields with underscores give TH machinery trouble #29

ozataman opened this issue May 15, 2014 · 6 comments

Comments

@ozataman
Copy link

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
Copy link
Owner

lykahb commented May 15, 2014

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
Copy link
Author

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
Copy link
Owner

lykahb commented May 15, 2014

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
Copy link
Author

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
Copy link
Owner

lykahb commented May 16, 2014

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
Copy link

yaitskov commented Oct 1, 2020

Workaround:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants