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

Add WARNING for camelized identifiers #208

Open
hisapy opened this issue Nov 16, 2016 · 7 comments
Open

Add WARNING for camelized identifiers #208

hisapy opened this issue Nov 16, 2016 · 7 comments

Comments

@hisapy
Copy link

hisapy commented Nov 16, 2016

As a schema writer I want a big WARNING when I write a camelized identifier, i.e.: field :someField in order to avoid possible errors when querying/mutating the schema.

@jparise
Copy link
Contributor

jparise commented Nov 16, 2016

This seems related to #185.

@hisapy
Copy link
Author

hisapy commented Nov 16, 2016

I believe yes

@benwilson512
Copy link
Contributor

Just to start the discussion, keep in mind that this is a bit hard at the moment because adapters are a runtime phenomena. That is at compile time when the schema is built, we have no idea what convention you're gonna use.

@bruce
Copy link
Contributor

bruce commented Nov 23, 2016

Because regardless of which runtime adapter is being used, the internal representation will stay static (ie, the schema convention can't change), and because snake_case is conventional for Elixir, I think what we can do is tie a "default" adapter to the schema (and have the system-defined default be LanguageConventions), then have a schema's default adapter decide if a schema's definition warrants a warning.

Slated for v1.3's schema definition changes.

@benwilson512
Copy link
Contributor

@bruce do we want to go ahead with making non snake case field identifiers an error or warning?

@benwilson512
Copy link
Contributor

Note that it will likely help with stuff like #298

@bruce
Copy link
Contributor

bruce commented Apr 10, 2017

I think we should just error. :fooBar just seems wrong, and it complicates a ton of things we can figure out implicitly to deal with it.

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

No branches or pull requests

5 participants