As a Customer Success Engineer here at Looker, I’ve spent quite a bit of time working on a diverse set of models. More often than not, these are existing models that I did not create, but simply want to contribute a few incremental changes to. Sometimes it’s a walk in the park. Other times, it’s a labyrinthine rabbit hole.
And the difficulty of adding a new thing to a project, if you think about it, is a pretty good indicator of the future speed at which your organization’s analytic capabilities can grow, not to mention how easily you can onboard new analysts and developers, and a number of other success factors.
So, I decided to make the best of my rabbit hole experiences by putting together a style guide and ruleset to help others avoid ever getting into those situations in the first place!
Before we get on the main show, I will extend two words of caution.
In the interest of preventing problems down the road, I will be recommending some practices whose value is not immediately realized. I have tried to put rationales along with all of these rules to help explain why, but nevertheless some rules may be unpopular.
More importantly, this is a first draft and will hopefully be amended and expanded in the future, with your feedback. If you read the guide, I would greatly appreciate some comments here to help me understand where there is room for improvement.
Hi Rick! Did you notice the rules can be expanded by clicking on them? (I’ll add some CSS to make the cursor a pointer to make that clearer). Or was the expanded explanation not clear enough? N is supposed to be the number of columns in the key (legitimate values are 0 or any positive integer in base 10)
Thanks for this - style guides are useful for creating team cohesion. Opinionated is good - if customers disagree, they can create their own variant of the style guide.
One point. You suggest an alias ‘{n}pk_{column}’ for primary keys, e.g. ‘as 1pk_user_id’. Not all databases like identifiers that start with a digit (e.g. oracle, hsqldb). I suggest changing this rule to make it more portable.
That’s a good recommendation on the not starting with a digit. I’ll add it in a note as an acceptable variant for now, and next time I want to publish a “2.0” version with breaking changes and all, I’ll make that the default
Thanks for this guide! This is really useful stuff.
I would love to know your opinion on file organization in a LookML repo.
For example, where should I store derived table views? If I have a a base table (base_table.view.lkml) and I want to build a derived table off of it, do I build derived_table_base_table.view.lkml or do I define the view within the base_table.view.lkml.
I actually don’t have a preferred approach to file naming. However, I do think it’s important to have a predictable way to find views given some characteristics (such as primary key) to prevent duplication of logic. In fact, when writing this, I was considering having a naming convention around file names, but what realized that I actually want to do is to use my lookml parser to automatically build a sort of index of views into the LookML project as a markdown file. It’s on my to-do list!