You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As I recently discovered, for strictly typed dialects like BigQuery, updating the type of a column/field can be very difficult since you don't know where that field is referenced in join constraints.
So for example, the following could throw an error:
explore: a {
join: b {sql_on: ${b.pk1_b_id} = ${a.b_id} ;;}
}
view: a { dimension: b_id {type:string}}
view: b { dimension: pk1_b_id {type:number}}
As stated, this would the first linter-enabled rule that is not strictly locally scoped. (Contrast with PK rules which are mediated by a naming convention, so they are implementable as two separate rules, one which checks local conformance to the naming convention, and another which checks local conformance given the name).
Alternately, we could encourage defensive application of the new LookML type coercion operator (::type), if that operator does not apply unnecessary conversions when the field is already of the desired type, like so:
explore: a {
join: b {sql_on: ${b.pk1_b_id::number} = ${a.b_id::number} ;;}
}
view: a { dimension: b_id {type:string}}
view: b { dimension: pk1_b_id {type:number}}
I'm not sure which I would recommend, but wanted to create a place to discuss
The text was updated successfully, but these errors were encountered:
Possible enhancement...
As I recently discovered, for strictly typed dialects like BigQuery, updating the type of a column/field can be very difficult since you don't know where that field is referenced in join constraints.
So for example, the following could throw an error:
As stated, this would the first linter-enabled rule that is not strictly locally scoped. (Contrast with PK rules which are mediated by a naming convention, so they are implementable as two separate rules, one which checks local conformance to the naming convention, and another which checks local conformance given the name).
Alternately, we could encourage defensive application of the new LookML type coercion operator (::type), if that operator does not apply unnecessary conversions when the field is already of the desired type, like so:
I'm not sure which I would recommend, but wanted to create a place to discuss
The text was updated successfully, but these errors were encountered: