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

The join processor documentation ideas #136

Open
roll opened this issue May 18, 2020 · 0 comments
Open

The join processor documentation ideas #136

roll opened this issue May 18, 2020 · 0 comments

Comments

@roll
Copy link
Contributor

roll commented May 18, 2020

Hi, there are some ideas from @adyork regarding the join processor docs:


I have some suggestions for clarifying if you think it would be helpful. I tried to keep to the source/target model language.

  • if inner:
    • Target rows with no key match in the source will result in dropping the row from the target.
    • Source rows with no key match in the target will not be added to the target.
    • It uses the same principle as the SQL's inner join.
  • If half-outer (the default):
    • Target rows with no key match in the source will have "null" values in fields that originate from the source.
    • Source rows with no key match in the target will not be added to the target.
    • It uses the same principle as the SQL's left/right outer join. The target would be the equivalent of the left table in a LEFT JOIN, and the target would be the equivalent of the right table in a RIGHT JOIN.
  • if full-outer:
    • Target rows with no key match in the source will have "null" values in fields that originate from the source.
    • Source rows with no key match in the target will be added to the target with "null" values in fields that originate from the target.
    • It uses the same principle as the SQL's full outer join.

Essentially what I am trying to clarify is when there are key mismatches, whether the rows are dropped or added to the result with null values in fields that originated from either the source or target.

Also, it really matters when translating the LEFT/RIGHT join model to the target/source model to clarify which is considered the "target." Essentially, you can flip flop what you can consider a left or right join if you switch which resource is the source or target.

Also, if people seem to be still confused about joins and modes, what I have found useful when explaining this to people is to show them these types of circle diagrams. You could adapt these join-type circle diagrams from the SQL model to use the source/target model terms by replacing the table1&2 with source&target.
image

join

https://www.w3schools.com/sql/sql_join.asp

@roll roll changed the title Join documentation ideas The join processor documentation ideas May 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant