8000 We should never show incorrect metric results (caused by one-to-many or many-to-many joins) · Issue #961 · lightdash/lightdash · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

We should never show incorrect metric results (caused by one-to-many or many-to-many joins) #961

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
TuringLovesDeathMetal opened this issue Dec 8, 2021 · 16 comments
Open

We should never show incorrect metric results (caused by one-to-many or many-to-many joins) #961

TuringLovesDeathMetal opened this issue Dec 8, 2021 · 16 comments
Labels
✨ feature-request Request for a new feature or functionality
Milestone
👯‍♀️ Deduplicatin...

Comments

@TuringLovesDeathMetal
Copy link
Contributor
TuringLovesDeathMetal commented Dec 8, 2021 •
edited
Loading

Here's what I think we should do: https://www.notion.so/lightdash/Identifying-incorrect-metric-calculations-123b73303d4e4499bcd327f0423aae81

Description: What is it?

This should be short and sweet 🍬
How would you explain this feature in two lines to someone else at Lightdash?

"I have incorrect metric values in my results table caused by one-to-many or many-to-many joins."

We'll solve this by doing two things:

  1. knowing which metrics will cause problems in aggregations (incorrect answers).
  2. when you have these metrics, you won't be able to use them in your results table.
@TuringLovesDeathMetal TuringLovesDeathMetal added the ✨ feature-request Request for a new feature or functionality label Dec 8, 2021
This was referenced Dec 8, 2021
Closed
Closed
@owlas
Copy link
Collaborator
owlas commented Dec 8, 2021

This is fire Katie, thank you!!! 🔥

@stale
Copy link
stale bot commented Apr 4, 2022

Is this issue still relevant? There have been no updates for 60 days, please close the issue or keep the conversation going!

@stale stale bot added the stale Issue hasn't been updated for 60 days label Apr 4, 2022
Closed
Open
@jw-aleksandr-zolotukhin
Copy link
jw-aleksandr-zolotukhin commented Apr 15, 2023 •
edited
Loading

!!! Very great thing to have. I mean this part: we'll think about the next step in handling symmetric aggregates
Asked a question in community recently about it... now I got the answer.
Subscribing.

@stale stale bot removed the stale Issue hasn't been updated for 60 days label Apr 15, 2023
@stale
Copy link
stale bot commented Jun 14, 2023

Is this issue still relevant? There have been no updates for 60 days, please close the issue or keep the conversation going!

@stale stale bot added the stale Issue hasn't been updated for 60 days label Jun 14, 2023
@Kobold
Copy link
Contributor
Kobold commented Jun 14, 2023

Yes, this is a killer feature. Do not close the issue please.

@stale stale bot removed the stale Issue hasn't been updated for 60 days label Jun 14, 2023
@stale
Copy link
stale bot commented Aug 16, 2023

Is this issue still relevant? There have been no updates for 60 days, please close the issue or keep the conversation going!

@stale stale bot added the stale Issue hasn't been updated for 60 days label Aug 16, 2023
@hubertsl
Copy link

super important feature !

@stale stale bot removed the stale Issue hasn't been updated for 60 days label Sep 25, 2023
@Daniel-SalazarSoplapuco
Copy link

Indeed adding here to show user demand, this is very important, as it would also impact performance and cost when running these queries.

@justabi
Copy link
justabi commented Oct 3, 2023

also keen for this to be created! looker's handling via primary keys + option to sum_distinct etc is particularly nice

@qantasperth
Copy link

not stale, very important!

@fev4
Copy link
fev4 commented Mar 12, 2024 •
edited
Loading

hey there, does this mean the workaround at the moment is either:

  • creating one-to-one models
  • or during the join, use "distinct on" to force it into one-to-one which means forgoing using the join YML schema

is that right? just wanna understand what alternatives other people follow in order to handle this in a sane manner

I got a similar situation with a couple of tables having a one-to-many relationship and recalled having this type of problem in the past, this is what prompted me to search until I found this issue

@jasonlanderson
Copy link

+1 would love to have this

Open
@owlas
Copy link
Collaborator
owlas commented Jun 20, 2024

For everybody subscribing here, this is a current priority so expect updates!

@yu-iskw yu-iskw mentioned this issue Jul 30, 2024
Open
@lightdash-bot
Copy link
Collaborator

This issue was mentioned by a user in slack: https://lightdash-community.slack.com/archives/C03MG2VTR08/p1731945923941059?thread_ts=1731945923.941059&cid=C03MG2VTR08

@lightdash-bot
Copy link
Collaborator

This issue was mentioned by a user in slack: https://lightdash.slack.com/archives/C07MRATGAKY/p1743769713432319?thread_ts=1743769713.432319&cid=C07MRATGAKY

@lightdash-bot
Copy link
Collaborator

This issue was mentioned by a user in slack: https://lightdash.slack.com/archives/C08RYCQJJCV/p1747079419585859?thread_ts=1747079419.585859&cid=C08RYCQJJCV

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
✨ feature-request Request for a new feature or functionality
Projects
None yet
Milestone
👯‍♀️ Deduplicating metric results (ca...
Development

No branches or pull requests
0