Closed mightybyte closed 11 years ago
Maybe that is as simple as including a function like this.
transformNamingStyle :: (String -> String) -> NamingStyle -> NamingStyle
transformNamingStyle f NamingStyle{..} =
NamingStyle (f . mkDbEntityName)
(f . mkEntityKeyName)
(\a b c -> f (mkPhantomName a b c))
(\a b c -> f (mkUniqueKeyPhantomName a b c))
(\a b c -> f (mkUniqueKeyConstrName a b c))
(\a b c -> f (mkUniqueKeyDbName a b c))
(\a b c -> f (mkDbConstrName a b c))
(\a b c -> f (mkDbConstrAutoKeyName a b c))
(\a b c d e -> f (mkDbFieldName a b c d e))
(\a b c d e -> f (mkExprFieldName a b c d e))
(\a b c d -> f (mkExprSelectorName a b c d))
(\a b c d -> f (mkNormalFieldName a b c d))
(\a b c d -> f (mkNormalDbFieldName a b c d))
(\a b c d -> f (mkNormalExprFieldName a b c d))
(\a b c -> f (mkNormalExprSelectorName a b c))
You can impose global db naming convention with your own NamingStyle. But I think that NamingStyle transformation can be confusing so I prefer to define styles explicitly. The NamingStyle concerns both DB and codegen names, so it is easy to make wrong transforms. E.g., you would not expect mkNormalExprFieldName to return lowercase field constructor.
Is defining your own naming style not convenient enough? For reuse you can copy and modify or call existing styles like
myNamingStyle :: NamingStyle
myNamingStyle = NamingStyle {
mkDbEntityName = \dName -> map toLower $ mkDbEntityName suffixNamingStyle dName
...
Of course, it is boilerplate, but typically it is done only once for project. Though, perhaps transformations with individual functions would be safer.
The NamingStyle concerns both DB and codegen names, so it is easy to make wrong transforms. E.g., you would not expect mkNormalExprFieldName to return lowercase field constructor.
Yeah, I realized this when the code I posted above didn't work.
Is defining your own naming style not convenient enough?
It's pretty convenient. It's just that this one particular NamingStyle seems like it will be so common that it might merit some kind of explicit support.
Do you think that a conversion function from CamelCase to underscore_names and a NamingStyle using it would cover your use case?
Yep, definitely.
In Postgresql, field and table names with upper case letters are a pain to deal with. It would be really nice if there was a way to do a global transformation on db names so that I could have groundhog use names like
foo_bar
instead offooBar
.