I have an issue with Gooddata's (in)ability to fol...
# gooddata-cloud
m
I have an issue with Gooddata's (in)ability to follow the LDM DAG when filtering. In particular I have the following LDM (image 1). If I filter by "Sales Monthly History > Division", I can correctly show User IDs in the selected division (image 2). Now, if I try to also show Lead Owner History IDs, I would expect to see Lead Owner History IDs for users that are in the selected division. However, I get a warning and no filtering happens (image 3). Why is this? This seems like an extreme limitation for anything but basic analytical queries. Or is there a workaround I'm missing? Thank you.
This feels broken, to be honest.
s
there is no lineage between Division and Lead Owner History.
Division is in your Sales Monthly History Table
don't know how it would get filtered in.
unless you meant to filter on current division, then it would work. (I think)
m
Well, it's a DAG.
s
as soon as you go down the dag, you can't go up.
m
But.. it did go up correctly from Sales Monthly History to User.
s
you can always go up within the dag, just not across the dag
m
Steve, I hear you, and I think this is broken in GoodData. It limits all but the most simple analytical queries.
s
Oh yeah, I know. We've had to redesign our model to fit things like this in or move our keys around to support them.
m
It is a constant frustration to me and my team, and it makes me seriously question our investment in GoodData. I'm hoping someone from the product team can chime in and help clarify what we are supposed to do in this case and if this is going to be addressed.
s
can always save the insight and then replace /edit with /debug to download the query inside.
🙌 1
fair enough either way
m
Hi Michael, sorry to hear about the filter issue. As correctly pointed out by Steve, the reason the filter is not working is that there is no connection between the “Lead Owner History” and “Sales Monthly History” datasets, hence the warning stating that the filter may not affect some metrics in the insight. Note that the relationship between datasets is important because it determines what you slice by what and the direction of the arrow determines which dataset’s data can be analyzed (sliced) by the data from the other dataset. Unfortunately I am not aware of a workaround that could allow you to force the connection possibly at the metric level, but please let me invite you to take a look at the resources below to learn more about the topic: Relationships between Datasets Understanding the Logical Data Model
I would most definitely like to share your experience as product feedback. Could you please let us know how these relationships in the LDM should work ideally or how they should translate to the insight filtering?
m
Moises, I don't understand how I am supposed to connect the two data sets directly, without creating a cycle (also bad). Unless I am missing something? I would expect the filtering shown in image 2 to expand to image 3. In other words, I should only get Lead Owner History records that are joined to one of the 9 User IDs shown image 2.
Moreover, what I really want to do is get Call records based on the filtering values from the Sales Monthly History dataset. Essentially, take the previous description one step further: find all call records which are associated with the set of Lead Owner History objects, found in the previous step.
I guess, my frustration is that this seems like pretty straightforward graph traversal, so I don't understand why it doesn't work.
We're trying to migrate dashboards from Tableau, which has absolutely no problem with the described data.
m
Thanks for the additional details. I have reached out to you via DM to continue looking into this.
j
The tool is trying to protect users from incorrect results. When you have for example metrics from different fact tables in one report, it calculates each metric separately and merges results on conformed dimensions (drill across feature) instead of calculating everything using one SELECT statement which would lead to double counting issue (joining of fact tables which have M:N relation between them. That is why data model 1:N relationships need to be set properly in data model. There is M:N relationship between Lead Owner History Id and Division. In case you would display metric SUM(Call count - Total) by both Lead Owner History Id and Division without date filter, you would see possibly calls double counted. If you are aware of this risk, you may permit use of Division attribute over many-to-many by dragging arrow from Sales Monthly History to User dataset. It will let users be broken down or filtered by Sales Monthly History attributes (thanks to double sided arrow in data model) and use it together with facts about calls and its related attributes.
m
Jakub, that is a super helpful response. Thank you. Is this level of detail specified in the documentation anywhere and I missed it? In case it isn't, it would be helpful to have more discussion on "reachability" with concrete examples. It might also be a useful UI/UX addition to the model builder. I.e. when a user hovers over a dataset + fact/attribute, they can see how far it "reaches" via highlighting of other datasets. I'll play around with this more today and let you know if I have any other questions.
j
I feel as though the docs haven’t done a great job of explaining the appropriate mental model for this stuff. Mike’s original thought process above seems completely reasonable and natural and I’m sure I would’ve modeled the data the same way, without realizing the tradeoffs that I’m making or the corner that I’m painting myself into.
j
@Michal HauzĂ­rek did not you write any relevant articles to our blog in the past? If not, we should finally invest our time to document it
m
As far as I know there is this series of articles about data modelling in the Community, where this part specifically talks about how data model affects reporting capabilities. And there is also similar course in the GoodData University. But I am not sure if any of these can be found directly from the official documentation.
m
I had not see that link before, "Basic Rules of Data Modeling" - that is very helpful. Is it clearly linked from the docs? That's normally where I go for reference.
m
I am not sure if these articles are linked from within the documentation (most probably not), but the whole section “Community” with these articles and forum and also the section “University” with online courses are linked in the header of the documentation. Historically the documentation part was more about “how to do things” and sometimes the “why” part and broader context was more in the community articles. I believe this is recently being improved and we are putting more context also to the documentation, because it is for sure easier for users to have all information in one place. Still the community and university are useful resources and I would recommend checking them as well.
j
Actually I made the first version of the related DOC page and I put it there. True is that it is quite hidden in the middle of the page. Maybe we should put it higher and visually emphasize it. @Petr Kudlacek?
đź‘Ť 1
đź‘€ 1
m
Actually, it seems there are several places that mention the LDM - one in the “getting started” section (which has this link) and another in the “Model Data” section where such link is not present at the moment and then the “Model Data” article itself, which links it as well.