Feature: Add `exclusive_min` and `exclusive_max` to `range` validation #246

ivan-gj · 2023-04-01T18:52:41Z

Description

This pull request adds the ability to introduce exclusive_min and exclusive_max parameters (temporarily named exc_min and exc_max) to the range validation. With this new feature, users can specify whether the range should exclude the minimum and/or maximum values.

For example, if a user wants to validate that a height field is within the range of 0.0 (exclusive) to 100.0 (inclusive), they can now use the following code:

#[validate(range(exclusive_min = 0.0, max = 100.0))]
height: f32

This situation is mostly relevant to non-integers, but I added the feature to support all the currently supported types because... who am I to stop people from using this feature with integers? Sometimes, it even makes sense (your limit is 299 but it is cleaner to say exclusive_max = 300).

It also forbids from inserting both inclusive and exclusive "minimums" or "maximums", so this is not possible:

#[validate(range(exclusive_min = 0.0, min = 10.0))]  // error
height: f32

Motivation

Currently, the range validation in this crate only allows users to specify an inclusive range. However, there are cases where users may want to exclude one or both of the endpoints of the range.

I come from a Python background, and pydantic is an well known validation library that has this feature, which was probably the main motivation for me to do this, as I have had to use this kind of exclusive limitation in some particular cases.

Another reason why I decided to do this was to make it possible for developers of schemars to automate the JSON Schema generation of these kind of exclusive limits.

Changes

Aside from the feature itself, tests and documentation have also been updated to reflect the new arguments and their limitations.

If there is any other thing that should be added in this Pull Request, please point it out, and I will try and do it.

…validation

Keats · 2023-04-03T20:12:51Z

I can see the point of half open/closed interval but I've never seen excluding the first value of the range. When is that useful?

ivan-gj · 2023-04-03T20:56:34Z

Do you mean having something along the lines of (-180.0, 180.0]? Because that is definitely a thing (and I have actually used it).

Keats · 2023-04-04T13:08:02Z

How do you represent it with the Rust range syntax? I was thinking of just using that for the next version to represent the range (eg instead of min=1, max=3 have 1..3)

ivan-gj · 2023-04-04T13:29:10Z

I think it is not semantically the same "range".
The 1..10 range is a simple way of setting up an iterable of 1, 2, 3, 4, 5, 6, 7, 8, 9.

The range as it is understood in this repo (and in the JSON schema) is simply a validation of either <, >, >= or <=; or a sensible combination. Although slightly related for the specific case of integers... it is a completely different thing for real numbers.

Okay, I just checked, and it definitely seems like Rust's Range is quite more powerful than I expected.

Let me think about it... although I have a feeling that we should keep the min/max approach, at least as an alternative option.

ivan-gj · 2023-04-06T15:18:41Z

Hi!
I have thought about it and, I strongly believe that we should have an exclusive minimum. It is supported in other important validation libraries, such as pydantic, and expected in validation schemas such as the JSON schema, and it would be a bummer to be forced to write custom validations for such a simple x > exc_min validation.

I do believe, though, that using Rust's Range variations could be a very nice feature, and a nice addition to the range validation. But, as I said, and addition, more than a substitution.

The reasoning behind this is that, well, things become clunky once you want to represent things such as:

#[validate(range(max = 123.0))]

because you'd have to do something like:

#[validate(range(-f64::INFINITY..=123.0))]

And that is definitely longer, and clearly not that humanly readable. I'd say clearly a downgrade.

Doing a Range with an exclusive minimum is even uglier.

So, what I would do, is to keep the min, max, exc_min, and exc_max, and open a new PR adding support for X..Y and X..=Y cases as a nice-to-have (I'd give it a try).

What do you think?

Keats · 2023-04-06T16:30:17Z

I would rather use the API from https://marshmallow.readthedocs.io/en/stable/marshmallow.validate.html#marshmallow.validate.Range where you have min_inclusive/max_inclusive as bool to keep min/max.
If we add those though, the range syntax does not make too much sense since it might be confusing. You could do 1..=3 and max_inclusive=false

ivan-gj · 2023-04-07T17:43:02Z

I am not that big of a fan... I feel that it possibly exists because of the positional arguments min and max, that allow short declarations such as Range(12, 20); which is something impossible currently in validator... and it creates problems, such as that Range(12) technically means that the minimum value is 12, but it is not clear at all. Not a fan.

So, if applying the marshmallow system, the ugliest case would look like this:

#[validate(range(min = -180.0, max = 180.0, exclusive_min = true, exclusive_max = true)]

And with the proposed system in this PR, it would look like this:

#[validate(range(exc_min = -180.0, exc_max = 180.0))]

And honestly, I'd rather go with the later, but now that I'm thinking, this following one looks the best now to me:

#[validate(range(exclusive_min = -180.0, exclusive_max = 180.0))]

It feels a lot clearer than the marshmallow version; while it becomes more explicit in the "exclusive" tag.

ivan-gj · 2023-04-07T17:50:38Z

For what it's worth, I asked ChatGPT and it agrees that the 3rd option is better 😅

Keats · 2023-04-14T10:40:09Z

They are booleans in https://datatracker.ietf.org/doc/html/draft-wright-json-schema-validation-00#section-5.3 as well so if we want to eventually generate openapi/jsonschema files from it it might be better to match it imo

Nevermind they are numbers in openapi 3.1

ivan-gj · 2023-04-14T16:43:47Z

Yep, I was basing myself mostly on the latest JSON Schema validation specification:
https://datatracker.ietf.org/doc/html/draft-bhutton-json-schema-validation-01#name-exclusivemaximum

Keats · 2023-04-16T20:05:03Z

Can you add the full name (exclusive) and do it against #249 ?

ivan-gj · 2023-04-17T17:10:37Z

There it goes! 😃

Keats · 2023-04-18T16:06:07Z

validator_derive/src/validation.rs

    FieldValidation {
        message,
        code: code.unwrap_or_else(|| validator.code().to_string()),
        validator,
    }
 }

+fn collide<T>(first: &Option<T>, second: &Option<T>) -> bool {


I think it's easier to read without this function

ivan-gj · 2023-04-20T10:32:38Z

Okay, I'll remove it this weekend.

Keats · 2023-04-23T21:46:03Z

Thanks!

ivan-gj · 2023-04-24T08:04:07Z

You are welcome! It was a blast. Thank you for merging. Looking forward to the next release!

#246) * feat(range): add exclusive minimum and exclusive maximum for `range` validation * test(range): add tests for `exc_min` and `exc_max` range validation * docs: add docs for `exc_min` and `exc_max` for `range` validation * chore: rename `exc_min`, `exc_max` to `exclusive_min`, `exclusive_max` * chore(validation.rs): get rid of `collide` function

ivan-gj added 3 commits March 31, 2023 18:06

feat(range): add exclusive minimum and exclusive maximum for range …

5350044

…validation

test(range): add tests for exc_min and exc_max range validation

2f363f5

docs: add docs for exc_min and exc_max for range validation

046059b

ivan-gj changed the title ~~Feature: Adding exc_min and exc_max to range validation~~ Feature: Add exc_min and exc_max to range validation Apr 1, 2023

ivan-gj changed the base branch from master to next April 17, 2023 15:58

chore: rename exc_min, exc_max to exclusive_min, exclusive_max

a7eee47

ivan-gj changed the title ~~Feature: Add exc_min and exc_max to range validation~~ Feature: Add exclusive_min and exclusive_max to range validation Apr 17, 2023

refactor: adapt to new "trait" system

ceabb47

Keats approved these changes Apr 18, 2023

View reviewed changes

chore(validation.rs): get rid of collide function

8707aec

Keats merged commit 6471bae into Keats:next Apr 23, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feature: Add `exclusive_min` and `exclusive_max` to `range` validation #246

Feature: Add `exclusive_min` and `exclusive_max` to `range` validation #246

ivan-gj commented Apr 1, 2023 •

edited

Loading

Keats commented Apr 3, 2023

ivan-gj commented Apr 3, 2023

Keats commented Apr 4, 2023

ivan-gj commented Apr 4, 2023 •

edited

Loading

ivan-gj commented Apr 6, 2023 •

edited

Loading

Keats commented Apr 6, 2023

ivan-gj commented Apr 7, 2023

ivan-gj commented Apr 7, 2023 •

edited

Loading

Keats commented Apr 14, 2023 •

edited

Loading

ivan-gj commented Apr 14, 2023

Keats commented Apr 16, 2023 •

edited

Loading

ivan-gj commented Apr 17, 2023 •

edited

Loading

Keats Apr 18, 2023

ivan-gj Apr 22, 2023

ivan-gj commented Apr 20, 2023

Keats commented Apr 23, 2023

ivan-gj commented Apr 24, 2023

Feature: Add exclusive_min and exclusive_max to range validation #246

Feature: Add exclusive_min and exclusive_max to range validation #246

Conversation

ivan-gj commented Apr 1, 2023 • edited Loading

Description

Motivation

Changes

Keats commented Apr 3, 2023

ivan-gj commented Apr 3, 2023

Keats commented Apr 4, 2023

ivan-gj commented Apr 4, 2023 • edited Loading

ivan-gj commented Apr 6, 2023 • edited Loading

Keats commented Apr 6, 2023

ivan-gj commented Apr 7, 2023

ivan-gj commented Apr 7, 2023 • edited Loading

Keats commented Apr 14, 2023 • edited Loading

ivan-gj commented Apr 14, 2023

Keats commented Apr 16, 2023 • edited Loading

ivan-gj commented Apr 17, 2023 • edited Loading

Keats Apr 18, 2023

Choose a reason for hiding this comment

ivan-gj Apr 22, 2023

Choose a reason for hiding this comment

ivan-gj commented Apr 20, 2023

Keats commented Apr 23, 2023

ivan-gj commented Apr 24, 2023

Feature: Add `exclusive_min` and `exclusive_max` to `range` validation #246

Feature: Add `exclusive_min` and `exclusive_max` to `range` validation #246

ivan-gj commented Apr 1, 2023 •

edited

Loading

ivan-gj commented Apr 4, 2023 •

edited

Loading

ivan-gj commented Apr 6, 2023 •

edited

Loading

ivan-gj commented Apr 7, 2023 •

edited

Loading

Keats commented Apr 14, 2023 •

edited

Loading

Keats commented Apr 16, 2023 •

edited

Loading

ivan-gj commented Apr 17, 2023 •

edited

Loading