-
Notifications
You must be signed in to change notification settings - Fork 53
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
Generically derived schema reference names can clash #56
Comments
We observe similar issue with monomorphic types having identical names, but defined in different packages. I can assume that the same may happen inside single package if two modules define types with identical names. |
Agree
However, I am worried about unintended consequences here. It seems like this approach would make it possible that adding a new type to your schema (/ adding a new route to your API) could change the names of pre-existing types. To me this would be very unexpected. One (fairly manual) way around this would be to make the programmer choose how much disambiguation is required on a type-by-type basis (with some encoding such that a new definition can always be made distinct from any previous choices). Probably a |
Yeah, that's a downside. However, it is a relatively rare case which will occur only when changes introduce/remove name collisions and will affect only paths using relevant types. Also the behavior could be controlled with a flag, so end-user could choose what is more preferable: API names stability or readability at cost of potential name shift. Conceptually, data RenderNameOption
= AlwaysFullName
-- ^ Always use package+module+type
| Compact
-- ^ Like current behavior, but when required use package/module or their combination to prevent name clashes
Yeah, it's too "manual" but will work. Another drawback is that one needs tests to timely catch potential collisions. As another option I can also imagine compile-time check for name conflicts (though not sure it is doable, especially, for
module Foo1
data Foo
module Foo2
data Foo
import Foo1 qualified
import Foo2 qualified
type API = Get Foo1.Foo :<|> Get Foo2.Foo You can alter neither Foo1 nor Foo2, hence cannot affect name generation. The solution exists: newtype one of the conflicting names, but that's not ideal. |
With schemas for polymorphic types, we can have names of schemas clashing, leading to incorrect generation (i.e. inconsistent with aeson's generic
ToJSON
). This can happen if one has a typedata T_A
and alsodata T a
&data A
: the generated schema names forT_A
andT A
are identical!As a complete example, consider the program
which has the output
Notice that the two
T_B
schemas have overwritten each other -- a serialised value of typeA
will not match this schema.Since types cannot contain the character
-
, one possible solution would be to change the serialisation introduced in #19 to useunspace ' ' = '-'
, rather thanunspace ' ' = '_'
.The text was updated successfully, but these errors were encountered: