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

Natural Joins #723

Open
max-sixty opened this issue Jun 28, 2022 · 2 comments
Open

Natural Joins #723

max-sixty opened this issue Jun 28, 2022 · 2 comments
Labels
language-design Changes to PRQL-the-language

Comments

@max-sixty
Copy link
Member

Another idea on the Joins: https://docs.oracle.com/javadb/10.6.2.1/ref/rrefsqljnaturaljoin.html

A NATURAL JOIN is a JOIN operation that creates an implicit join clause for you based on the common columns in the two tables being joined. Common columns are columns that have the same name in both tables.

@max-sixty max-sixty added the language-design Changes to PRQL-the-language label Jun 28, 2022
@aljazerzen
Copy link
Member

Related discussion: https://news.ycombinator.com/item?id=31898312

The concern exposed was that if a database schema is changed this also changes the query, without throwing errors or warnings.

Another alternative proposal was "join paths":

    defjoin r,m,a = %prejoin_roles() -> {     # define a common join path between three relations r,m,a:
      from r=ROLES                            # can hard-code table names or use parameters (which may refer to other parameters)
      join m=MOVIES [r.movie_id = m.movie_id]
      join a=ACTORS [r.actor_id = a.actor_id]
    }

    from r,m,a = %prejoin_roles()
    select m.title, a.character_name

We are planning to have some kind of schema definition as a part of the language, so this is not so far off. But I not quite sure on what exactly is the problem we are trying to solve here.

@snth
Copy link
Member

snth commented Jun 29, 2022

Just to point out that if the database schema is changed, then potentially any query with a SELECT * might change so even something simple like:

from tbl

There were a lot of good points in that thread, like avoiding ambiguity, allowing you to specify not to use FKs when required, etc ...

I still want to go over it again but the one that stood out to me was using the FK name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
language-design Changes to PRQL-the-language
Projects
None yet
Development

No branches or pull requests

3 participants