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

Handle x nullable for enums #191

Merged
merged 4 commits into from May 14, 2018

Conversation

twiden
Copy link
Contributor

@twiden twiden commented Jan 18, 2018

I've noticed that enums don't work very well with x-nullable=True. I had to include null/None as an enum value for the validation to pass, but that combo of x-nullable and enum value does not work with swagger-ui.
So I suggest this change.
costumes-for-dogs-banana-dog

@twiden
Copy link
Contributor Author

twiden commented Feb 1, 2018

Hi
Could I get some feedback on this? It would be much appreciated

Thank you

@pipermerriam
Copy link
Owner

I'm hesitant to add this, at least as a feature that's enabled by default.

My reasoning is that IIUC x-nullable is not part of the core spec, and is more of a convention. Assuming that is correct, it strikes me that this feature should require explicit opt-in using something like an environment variable or configuration flag.

Thoughts?

@twiden
Copy link
Contributor Author

twiden commented May 7, 2018

From a user perspective I think that if I specify both x-nullable=True and enum=[x, y, z], I'm pretty explicit about null being an expected value. This does not add unexpected behaviour to an enum field, but makes the x-nullable extension apply correctly to enums (In my opinion)

However: I see your point about it not being in the core spec and you are the one who will have do deal with questions from users about this behaviour. So if you still think it should be disabled by default I suggest an environment variable X_NULLABLE_ENUMS or similar.

I can rewrite the PR with this change if you think that's the way to go.

@pipermerriam
Copy link
Owner

Alright, took a night to think it over.

I'd like to meet in the middle. Your user perspective argument holds water for me, but I want a way for people who want strict validation to be able to have it (i.e. not supporting x-nullable).

If you'll update this PR so that x-nullable support is enabled by default, but it can be disable if the environment variable FLEX_DISABLE_X_NULLABLE is set (to anything), then we can get this merged and released.

@@ -297,7 +298,7 @@ def validate_enum(value, options, **kwargs):


def generate_enum_validator(enum, **kwargs):
if kwargs.get('x-nullable') is True:
if not os.environ.get(FLEX_DISABLE_X_NULLABLE) and kwargs.get('x-nullable') is True:
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This check should probably be if FLEX_DISABLE_X_NULLABLE not in os.environ and ... for the case where it's set to an empty value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

tests/utils.py Outdated


@contextlib.contextmanager
def set_env(**environ):
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you update this to use the monkeypatch fixture provided by pytest. It automatically cleans up anything that you patch during test runs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@twiden
Copy link
Contributor Author

twiden commented May 14, 2018

Good feedback :) Thanks!

@pipermerriam pipermerriam merged commit 5098449 into pipermerriam:master May 14, 2018
@twiden twiden deleted the handle-x-nullable-for-enums branch May 15, 2018 06:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants