The join processor documentation ideas #136
Description
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
