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.
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
feat: EXPOSED-560 Support DISTINCT ON from Postgres #2275
feat: EXPOSED-560 Support DISTINCT ON from Postgres #2275
Changes from 3 commits
7a67160
667fe1d
7cc0529
4f41be1
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
(minor) with this implementation it would currently be allowed to -- arguably unintentionally -- add an entry to
orderByExpressions
twice for a DISTINCT ON column (since that attribute is a list and not a distinct set), e.g.postgresql allows for this and uses the last specified sorting predicate specified for a column but i'm not sure if you're intentionally supporting this use case; i don't personally know if the behaviour of having a column mentioned twice in
ORDER BY
is consistent across all sql dialects.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.
Thank you for the feedback,
when I was adding the option of
withDistinctOn
with ordering I also thought that it could cause misunderstanding,In general, the main purpose of that variant is make a use case when there is only distinctOn without extra ordering simpler, and prevent necessity to call
orderBy
right afterwithDistinctOn()
with the same columns order, what could be broken on any refactoring.So my expectation at the current moment that for any complex logic of adding ordering, the version
withDistinctOn(vararg columns: Column<*>)
(without ordering) should be used.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.
note that if
withDistinctOn()
is called afterorderBy()
(which i think is technically possible) then the ordering may be incorrect (DISTINCT ON at least in postgresql requires the specified columns to appear in the ORDER BY expression in the same order), e.g.i think results in
ORDER BY table.col_three, table.col_one, table.col_two
which generates a SQL error.a possible solution would be to manipulate the underlying
orderByExpressions
mutable list directly to prepend the list of columns passed in, instead of callingorderBy()
. something like:(since
private set
on the declarationorderByExpressions
prohibits redefining the var)