-
Notifications
You must be signed in to change notification settings - Fork 35
fix up treatment of null restrictions #971
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
Conversation
we need this because "== NULL" and "IS NULL" aren't the same thing
| */ | ||
| package jakarta.data.metamodel.restrict; | ||
|
|
||
| public enum UnaryOperator { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not here?
I mean, those are Operator, right?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right.
There was a problem hiding this 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
api/src/main/java/jakarta/data/metamodel/restrict/UnaryOperator.java
Outdated
Show resolved
Hide resolved
api/src/main/java/jakarta/data/metamodel/restrict/UnaryRestriction.java
Outdated
Show resolved
Hide resolved
api/src/main/java/jakarta/data/metamodel/restrict/UnaryRestrictionRecord.java
Outdated
Show resolved
Hide resolved
| */ | ||
| package jakarta.data.metamodel.restrict; | ||
|
|
||
| public enum UnaryOperator { |
There was a problem hiding this comment.
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.
api/src/main/java/jakarta/data/metamodel/restrict/Restrict.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Nathan Rauh <[email protected]>
This makes the following changes:
UnaryRestrictionandUnaryOperatorto representis nullandis not null.nullas a value inBasicRestriction, since the meaning of= nulland<> nullvaries between datastores.