izzy, I have a further question on this. We’re currently using this in an extended model, where the same table is referred multiple times, once in the original model, the second in the extended part (to join back to the original model).
This is in order to tie data back to a calendar view, and allow the same logical joins of data, but would allow that same logical set to be queried based on different event dates, e.g. application date, deal date and so on. The reason we used an extended model is so we didn’t need to maintain the logical joins more than once, just the anchor for the date selection.
The original SQL output for this would actually result in just a single join to that table, as the lookML implementation seemed clever enough to realise that’s what we’re doing.
However, with using sql: in the extension we now get errors for that table where it’s complaining about having both a sql: and sql on: parameter for the same table. I can get around this by using a different name in the extension, however this then results in two joins. Which is fine, but has a bit of an impact on performance and readability.