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

Add support for unbounded ranges #350

Closed
lukaseder opened this issue Jun 19, 2019 · 5 comments
Closed

Add support for unbounded ranges #350

lukaseder opened this issue Jun 19, 2019 · 5 comments

Comments

@lukaseder
Copy link
Member

The org.jooq.lambda.tuple.Range type currently supports only bounded ranges. It would be nice to support also unbounded ranges, where null corresponds to "infinity".

For example:

// From 1 to infinity
new Range(1, null);

// From -infinity to 1
new Range(null, 1);
@tlinkowski
Copy link

Just for reference (in case you wanted to further improve your ranges), Guava has quite advanced range support (including e.g. open/closed bounds).

Artus2b added a commit to Artus2b/jOOL that referenced this issue Jun 20, 2019
org.jooq.lambda.tuple.Range class does not support nullable bounds.
However in PostgreSQL a lower range bound of value 'null' means '-infinity'.
See the [Range Types documentation](https://www.postgresql.org/docs/11/rangetypes.html#RANGETYPES-INFINITE):
> The lower bound of a range can be omitted, meaning that all points less than the upper bound are included in the range.

E.g. when testing that the range '(,3)' contains the value '-12':
# SELECT '(,3)'::INT4RANGE @> -12;
 ?column?
----------
 t
(1 row)
Artus2b added a commit to Artus2b/jOOL that referenced this issue Jun 20, 2019
org.jooq.lambda.tuple.Range class does not support nullable bounds.
However in PostgreSQL a lower range bound of value 'null' means '-infinity'.
See the [Range Types documentation](https://www.postgresql.org/docs/11/rangetypes.html#RANGETYPES-INFINITE):
> The lower bound of a range can be omitted, meaning that all points less than the upper bound are included in the range.

E.g. when testing that the range '(,3)' contains the value '-12':
# SELECT '(,3)'::INT4RANGE @> -12;
 ?column?
----------
 t
(1 row)
@Artus2b
Copy link

Artus2b commented Jun 20, 2019

@tlinkowski Indeed I found the Guava and Apache Common Ranges implementations, while I was writing the algorithm of overlaps(Range a, Range b) which was a bit cumbersome.
Are you saying those libs nullify the usefulness of the issue? Or that we should use Guava's implementation in the proposed fix?

Edit: in any case here's my PR #351 :) I'd be happy to know what you think.

@tlinkowski
Copy link

Are you saying those libs nullify the usefulness of the issue? Or that we should use Guava's implementation in the proposed fix?

@Artus2b I don't know which is best here. In your PR, you mentioned how it works in PostgreSQL, so aligning to its Range Types (independently of other libs) in certainly one option.

To sum up, I'm just saying it's good to be aware of other solutions (thx for mentioning Apache Commons - forgot about that) so that an informed decision can be made.

@lukaseder
Copy link
Member Author

Are you saying those libs nullify the usefulness of the issue?

Everything jOOλ does is available in one way or another through a different means. After all, we're all working with turing complete languages, so everything is possible, including NIH, home grown solutions to every single problem :)

Given that we already have a Range type, it's definitely worth exploring what else it can offer, and I do like this idea, regardless of what Guava does.

@lukaseder
Copy link
Member Author

I think that all changes from your PR are now addressed:

  • Documentation of inclusivity of current range implementation
  • (Partially) Unbounded ranges
  • Range.contains()

Thanks again for your suggestion and PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants