Respect writeOnly ?

[georgkrause]

Hello everyone,

thanks for the great project, great work! Keep it going!

I am totally new to the whole openapi universe and its a great adventure. The API I am working with is not really perfect and has a lot of issues I need to work on, but one thing I noticed is a bit weird:

My API has types with fields that are specified with writeOnly, which seems to me like an indicator this field is only available when sending data to the API. But when I generate the python client using this lib and run a GET request against the endpoint, the deserialization fails because the field is expected but missing.

This seems to be a common issue, since my generator (DRF-Spectacular) even has documentation for this: https://drf-spectacular.readthedocs.io/en/latest/client_generation.html?highlight=writeonly#component-issues

And indeed, turning on the component split solves the problem. Nevertheless, I am not sure if this something openapi-python-client should respect, according to the specs? For now its just a question, as I said I am a newbe and happy to learn my lessons here. If you consider this to be something to work on, I won't mind creating an issue for this.

Thank you a lot and hive a nice day 🌥️

[dbanty]

writeOnly isn't supported yet in this project, but it should be added eventually. I opened an issue to track that 😊

[georgkrause]

Great, thank you!

I am not sure how your interaction between issues and discussions work, so I hope its fine to reply here. Anyways, if you don't mind and provide me some pointer, I might be able to look into this and contribute a PR!

[dbanty]

The general approach will probably be to generate two models when writeOnly or readOnly are present for any properties. The two go together, so it makes sense to implement them together, I think. I imagine this will happen within or near update_schemas_with_data.

Then, in those cases, something tricky will have to happen. These properties only really matter for shared references, so each shared reference now needs to be optionally split into a write_model and read_model and assigned as appropriate. So the type of Schemas.classes_by_reference will probably change to something like Dict[_ReferencePath, Union[Property, SplitProperty]] where SplitProperty is a new class that defines separate reader and writer properties.

Then, property_from_data will probably have to be updated to take in a parameter that specifies whether the property in question is used in a read or write context, that way, it can provide that info to any lookup of references, which may now be SplitProperty (or whatever it's called).

Probably a lot of nuisance and complexity will arise from implementing it, but that's my first idea of how it could work. The main thing is that I think it's better to generate two models in these cases, not one that handles things at runtime.