Re-using extended explore in same explore

_Noah
Participant III

Hello,

Our team has been working toward cleaning up our models that have become bloated and difficult to navigate over the years. One of the key things we failed to implement when starting was a system of DRY LookML. This has lead to repetitious joins, views, and explores throughout our models. The current pain point we have yet to find a solution for is re-using an explore that has been modeled for extension.

An example of this is the idea of what a user is. Once we model those attributes and join in the various tables we can have a rather long explore that is just dying to be extended over other explores. The problem comes in where we have to re-use this extended explore and join again in that same explore. Take our example- users. Let’s say users can be buyers or sellers. What happens when we want to provide details, from our users explore, for both user types for something like a sale? We appear to have no way. Once the extended explore (users) has been joined to either the buyer ID or seller ID it cannot be re-joined. At least, that is our current understanding. And with that we are forced to either:

A) Create an explore (for extending purposes only) for every entity type (we may not only have buyers and sellers but we may have buyer managers, seller representatives, sale middlemen, etc). The maintenance nightmare begins with this idea.
or
B) Put our explore used for extending (like Users) into an natural derived table and join that repeatedly. But what if our explore has many fields? What if the explore, for extending, has complex joins that rely on multiple views that are extensions of a view in the same explore (answer- we have to manually spell each dim and measure out in this explore. This begs the question of why we did begin with making the explore, built for extension?)

I am hoping someone has solved this. I feel like there’s gotta be at least one other org out there that has the same situation. We’re open to ideas assuming they don’t lead to maintenance nightmares and are practical to implement.

  • Noah
2 0 138
0 REPLIES 0
Top Labels in this Space
Top Solution Authors