Remove the associated type from SelectableExpression
#774
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sgrif
added a commit
that referenced
this pull request
Mar 4, 2017
I spotted this while working on #774. This method is not part of the public API, and is useless now that `sql` exists. I've skipped adding a changelog entry since this doesn't affect public API.
This removes the flawed "SQL type varies based on the query source" design in favor of "things become nullable if they're on the wrong side of an outer join". This means that columns from the right side of a left join can no longer directly be selected. `.nullable` must be manually called. This sounds like a huge deal, but that's already the case today with tuples (which is a more common case), and it hasn't caused a huge ergonomics issue. Ultimately most queries just use the default select clause. This also causes the nullability to bubble up. If you're building a compound expression that involves a column from the right side of a left join, you don't have to worry about that in the compound expression. You just have to make the whole thing nullable at the top level. This mirrors SQL's semantics quite nicely. One downside of this is that `.nullable` can no longer be used in arbitrary select clauses. Doing so is questionably useful at best, but I'd still like to bring back that support in the future. Ultimately doing so more requires rust-lang/rust#40097 or similar.
sgrif
force-pushed
the
sg-rm-selectable-expression-type
branch
from
fdefafa to
6a8deb2
Compare
killercup
approved these changes
Mar 4, 2017
There was a problem hiding this comment.
Looks good to me.
Not sure about the possible errors user see, though. How would they discover they need to call .nullable on (some item in the) select param? I'd probably add a note to left_outer_join, as this is a place I'd look for an explanation.
| /// type is usually the same as `Expression::SqlType`, but is used to indicate | ||
| /// that a column is always nullable when it appears on the right side of a left | ||
| /// outer join, even if it wasn't nullable to begin with. | ||
| /// Indicates that an expression can be selected from a source. Columns will |
There was a problem hiding this comment.
Would begin a new paragraph after the first sentence
| /// outer join, even if it wasn't nullable to begin with. | ||
| /// Indicates that an expression can be selected from a source. Columns will | ||
| /// implement this for their table. Certain special types, like `CountStar` and | ||
| /// `Bound` will implement this for all sources. Most compound expressions will |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This removes the flawed "SQL type varies based on the query source"
design in favor of "things become nullable if they're on the wrong side
of an outer join". This means that columns from the right side of a left
join can no longer directly be selected.
.nullablemust be manuallycalled. This sounds like a huge deal, but that's already the case today
with tuples (which is a more common case), and it hasn't caused a huge
ergonomics issue. Ultimately most queries just use the default select
clause.
This also causes the nullability to bubble up. If you're building a
compound expression that involves a column from the right side of a left
join, you don't have to worry about that in the compound expression. You
just have to make the whole thing nullable at the top level. This
mirrors SQL's semantics quite nicely.
One downside of this is that
.nullablecan no longer be used inarbitrary select clauses. Doing so is questionably useful at best, but
I'd still like to bring back that support in the future. Ultimately
doing so more requires rust-lang/rust#40097 or
similar.