Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@gavinking
Copy link
Contributor

This makes the following changes:

  1. Introduces UnaryRestriction and UnaryOperator to represent is null and is not null.
  2. Disallows null as a value in BasicRestriction, since the meaning of = null and <> null varies between datastores.

*/
package jakarta.data.metamodel.restrict;

public enum UnaryOperator {
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

A BasicRestriction can have a (binary) Operator. A UnaryExpression can have a UnaryOperator. Type safety calls for them to be different types.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree, as long as BasicRestriction and UnaryRestriction are two separate classes, it makes sense to have Operator and UnaryOperator. If we didn't have UnaryRestriction and instead BasicRestriction represented both, then it would make sense to have only Operator. The case for keeping them separate would be that the value() of BasicRestriction is unused in the case of unary. The case for combining them would be having less interfaces/classes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right.

Copy link
Contributor

@njr-11 njr-11 left a comment

Choose a reason for hiding this comment

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

Looks good - thanks for correcting this! I added a few minor comments/suggestions

*/
package jakarta.data.metamodel.restrict;

public enum UnaryOperator {
Copy link
Contributor

Choose a reason for hiding this comment

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

I agree, as long as BasicRestriction and UnaryRestriction are two separate classes, it makes sense to have Operator and UnaryOperator. If we didn't have UnaryRestriction and instead BasicRestriction represented both, then it would make sense to have only Operator. The case for keeping them separate would be that the value() of BasicRestriction is unused in the case of unary. The case for combining them would be having less interfaces/classes.

@otaviojava otaviojava merged commit 4e720be into jakartaee:main Feb 14, 2025
4 checks passed
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.

3 participants