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

Check for valid/invalid values after conversion only #1623

Closed
pigeonvictor opened this issue Oct 25, 2018 · 2 comments
Closed

Check for valid/invalid values after conversion only #1623

pigeonvictor opened this issue Oct 25, 2018 · 2 comments
Assignees
Labels
breaking changes Change that can breaking existing code feature New functionality or improvement
Milestone

Comments

@pigeonvictor
Copy link

Describe the problem you are trying to fix (provide as much context as possible)

Let's assume I have this validation schema :

Joi.object().keys({
foo : Joi.number()
});

With this schema both of this object will be validated since Joi works with number as strings :

let a = {foo : 42};

let b = {foo: "42"};

It's perfectly right for me, but the problem comes when I'm trying to work with the valid() method :

Joi.object().keys({
foo : Joi.number().valid([41, 42, 43])
});

//this schema will validate the a object but not the b object

Is there any way to validate the b object in a more elegant way than :

Joi.object().keys({
foo : Joi.number().valid([41, 42, 43, "41", "42", "43"])
});

Which API (or modification of the current API) do you suggest to solve that problem ?

Maybe add a flag to the valid method ?

Are you ready to work on a pull request if your suggestion is accepted ?

Yes

@Marsup
Copy link
Collaborator

Marsup commented Oct 25, 2018

Is there an actual use case? Are those numbers always integers in a range?

@Marsup Marsup added the request label Oct 25, 2018
@pigeonvictor
Copy link
Author

More details :
I'm parsing XML files so numbers are somehow parsed in strings.
This numbers should match some emuns, so they are integers but not necessary in a range (so I cant use min / max).

What would be perfect for me is that the convert option is also used for valid

@hueniverse hueniverse self-assigned this Jun 1, 2019
@hueniverse hueniverse added this to the 16.0.0 milestone Jun 1, 2019
@hueniverse hueniverse added the breaking changes Change that can breaking existing code label Jun 1, 2019
@hueniverse hueniverse changed the title Validation with ambiguous number values Check for valid/invalid values after conversion only Jun 2, 2019
@Marsup Marsup mentioned this issue Jun 9, 2019
@hueniverse hueniverse added the v16 label Aug 10, 2019
@hueniverse hueniverse added feature New functionality or improvement and removed request labels Sep 19, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Mar 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
breaking changes Change that can breaking existing code feature New functionality or improvement
Projects
None yet
Development

No branches or pull requests

3 participants