-
Notifications
You must be signed in to change notification settings - Fork 9
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
Schema mixes snake and camel case? #150
Comments
Also, the manifest spec mentions a key called |
Thanks! I think it would be worth normalizing this in the current draft indeed. |
fsteeg
added a commit
that referenced
this issue
Apr 11, 2024
While snake_case took over in the draft, camelCase is the common convention in the manifest, so this seems to be the sensible choice
fsteeg
added a commit
that referenced
this issue
Apr 11, 2024
Noticed while unifying naming for #150
fsteeg
added a commit
that referenced
this issue
Apr 11, 2024
fsteeg
added a commit
that referenced
this issue
Apr 11, 2024
wetneb
pushed a commit
that referenced
this issue
Jun 13, 2024
* Unify naming to camelCase convention (#150) While snake_case took over in the draft, camelCase is the common convention in the manifest, so this seems to be the sensible choice * Update draft examples and schemas for removed fields Noticed while unifying naming for #150 * Update "This Draft" section for camelCase naming (#150, #162)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Why does the API mix camel and snake case? The service manifest has keys named
identifierSpace
,schemaSpace
,defaultTypes
feature_view
Presumably you would want to use one or the other? Is it that you are using snake for objects and camel for values/arrays? But later in suggest metadata you use
service_url
to refer to a string? I'm confused.The text was updated successfully, but these errors were encountered: