-
Notifications
You must be signed in to change notification settings - Fork 20
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
Feature Request: Allow deserialization of hyphenated fields #132
Comments
Reason this doesn't work today is due to the rules defined in the test-cases yml file: https://github.com/palantir/conjure-verification/blob/85ec2c15cde616415e79d6b3b03c34559e287ab0/master-test-cases.yml#L390
For example: Given a generated conjure bean like so:
Called like this:
And this implementation:
which passes through to
This fails with the above exception:
When it shouldn't given the conjure client generator separates it out with underscores already and is fairly straightforward to at least look for it. "file_system_id": ConjureFieldDefinition("fileSystemId", str), |
What happened?
Describe what you've observed and why it's bad (please include whatever stacktraces/version numbers you can).
Clear steps to reproduce the behaviour are always helpful too!
A very common use case for this type of capability is the ability to easily serialize/deserialize typed objects from a shared interface, but we need the ability to be a bit more flexible when deserializing objects into Conjure classes or we're going to need to use a different tool to share interfaces (which would be a bummer since I think its the right tool here).
Example:
Input object (python dictionary):
{ "foo-bar": "baz" }
Desired Conjure Object:
Banana(foo_bar: baz)
Currently - this will result in an empty
Banana(FooBar: None)
object which can potentially be misleading.What did you want to happen?
I realize that having strict standards is generally a good thing, especially in an area with mostly solved problems (like IR object representation), so I am not proposing any changes in the default behavior.
Instead, I am arguing there should be a separate, non-standard set of "DecodingOptions" that should be available to the user upon request - with, for example, an option to loosen restrictions around deserialization and allow fields with hyphens to be able to deserialize into objects.
An implementation of what this might look like: PR- #131
The text was updated successfully, but these errors were encountered: