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

What does it mean to merge different kinds of selects? #373

Open
seancorfield opened this issue Dec 4, 2021 · 3 comments
Open

What does it mean to merge different kinds of selects? #373

seancorfield opened this issue Dec 4, 2021 · 3 comments
Assignees
Labels
needs analysis I need to think about this!

Comments

@seancorfield
Copy link
Owner

Right now, each type of select is considered a completely different clause so "merging" them simply doesn't work. You can merge select with itself. You can merge select-distinct-on with itself (since #372 got fixed). You can merge select-distinct with itself. You cannot merge select-top or select-distinct-top with itself (because the first argument is "special" and merging just concatenates arguments).

But the question is really: what should merging those types of selects really do?

  • if you merge select-distinct and select, the result could safely be select-distinct with all the columns merged
  • similarly, if you merge select-top and select, the result could safely be select-top with its first argument and then all the columns merged
  • similarly, for select-top and select-distinct, the result could safely be :select-distinct-top with the first arg from select-top and then all the columns merged

What about the other combinations? What should select-top merged with select-top do? An error? Overwrite one top expression with the other silently?

@seancorfield seancorfield self-assigned this Dec 4, 2021
@seancorfield seancorfield added the needs analysis I need to think about this! label Dec 4, 2021
@seancorfield
Copy link
Owner Author

I'm beginning to wonder if having a generic :select+ might be a good idea, where the first argument is a sequence of qualifiers to use, and merging it could handle the logic in some sort of intuitive way. That wouldn't address the select-distinct/select merge, although perhaps select+ could check if there's a select in the DSL and "upgrade" it to a select+?

{:select+ [:distinct :a :b :c] ...}
{:select+ [[:top 5] :a :b :c] ...}
{:select+ [[:distinct [:top 10]] :a :b :c] ...}

@Tillaert
Copy link

Tillaert commented Apr 6, 2024

I was running into this problem today:
I have a function that takes a sql query as input. I need to append something to the select in both cases, but one is using :select and the other is using a :select-distinct-on.

Of course I could look into the query to see what type of select it uses.

Being a bit of an edge-case, an (append-to-select query :column-name) type of function might just be enough? We are just manipulating datastructures here.

@seancorfield
Copy link
Owner Author

That's a different problem. This issue is about the helper functions specifically and what should happen if you use one of the select... helpers to merge something into an existing query that was built with a different select... helper.

In your case, your function could either check specifically for :select or :select-distinct-on and append to the argument of whichever it finds. But the general case could have symbols rather than keywords and could be any of the selection DSL clauses which have different semantics for their arguments.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs analysis I need to think about this!
Projects
None yet
Development

No branches or pull requests

2 participants