WN 0001: Adding 'relationships' to Malloy

[lloydtabb]

See Current Proposal at:

https://github.com/malloydata/whatsnext/blob/main/wns/WN-0001/wn-0001.md

[mtoy-googly-moogly]

1. This is also going to require support in the IL, there is no way to generate structdefs for two objects which join each other.

2. I feel like the use of punctuation salad for describing a join relationship is very different than our philosophy on things like this up until now and would prefer something involving words.

3. Not sure about the gesture to link through ... I absolutely don't like @ because that means "date literal" ... I have some other suggestions

• No sigil, by putting functions the global scope, the "keep the namespace clean for columns" ship sailed a long time ago
• A different de-reference than "." to mean "through a reference" something like relationName->fieldName except we already usesd -> ... but something like that
• Keep using . but have an explicit gesture to import a relation into the expression space, which would allow a source to rename the relation ( or even repeat it with different names )

[lloydtabb]

Some notes from discussions.

@mtoy-googly-moogly asks "Why the @ sign? We are already Using that". @lloydtabb replies "In SQL @foo means that foo is a global variable".

As to the implementation, the compiler could composite a StructDef for a query and resolving any relationships by looking at the field references in a query.

@mtoy-googly-moogly notes that @christopherswenson would like to formalize function names spaces and maybe that needs to be resolved at this point...

[christopherswenson]

Comment from @kylenesbit on Slack:

I would like to be able to define a join relationship from both sides of the relationship. For example,
source a is ... { join_one: b on b.id = a.id }
source b is ... { join_one: a on a.id = b.id }
So folks starting an analysis on source a can easily find the relationship to source b -- and vice versa. However, Malloy doesn't support this today since the symbol 'b' is undefined when it is first referenced in the example above. Has there been any thoughts on supporting this type of forward reference (or declaration)?
In the meantime, I can think of a few workarounds, but am curious to see if anyone has any pointers / patterns for this type of scenario.

[kektobiologist]

can you share what workarounds @kylenesbit figured out? I can't access the slack discussion since its more than 90 days old