-
Notifications
You must be signed in to change notification settings - Fork 60
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
ObjectSchema member.Key.ToCamelCase() ignores underscores #167
Comments
Does this still happen if you make If you change it from a property to a member variable But you're right, the |
The code is working as expected in terms of You can fix this by changing the class to be like: [Model("This is my class")]
public class MyClass
{
[JsonIgnore]
[ModelProperty(Ignore = true)]
public string _isSeven { get; set; }
public bool IsSeven
{
get
{
return _isSeven == "True";
}
set
{
_isSeven = value ? "True" : "False";
}
}
} Let us know if that resolves your error! |
Thanks, @jnallard, I was forgetting to do that! But, while adding that hides the annotated properties from the Model schema, it doesn't prevent exceptions from being thrown for similarly named variables. Still, when I access Here is a stacktrace:
Thank you |
Hmm. Otherwise, if you want to make a pr to keep the starting |
Ok, I do admit I didn't open up the sample project before replying that it doesn't work -- I did it directly in my own project. I'll spend a little more time on it. Thanks! |
Expected Behavior
I have class like this:
I expect including this class in the ModelCatalog to not totally bork the Nancy.Swagger
/api-docs
route. I also expect it not to add_isSeven
into the Schema Properties, or at least to do so under a different name.Taking a look at the relevant code, the object properties are normalized using
member.Key.ToCamelCase()
, which maps bothIsSeven
and_isSeven
to the same string,isSeven
.While I understand (and enjoy) normalization to camelCase, in the project I am working on, it is the convention to name sometimes name an underlying property the same as the public property, but prefixing the name with an underscore, eg
IsSeven
and_isSeven
to be ultra pedantic. At the very least, the[ModelProperty(Ignore = true)]
ought to fix this behavior (the error message for which is obtuse), or another property.I hesitate to introduce Nancy.Swagger to my colleagues when I know that they will eventually have their swagger docs broken after trying to include a particular model.
Steps to Reproduce the Problem
Specifications
2.2.53-alpha
through and includingmaster
Nancy.Swagger
Thank you,
Sam Berney
The text was updated successfully, but these errors were encountered: