We are getting a very rare issue, which has been reported by only one of our clients.
For a certain query, which is correctly groupped by, we get some row duplicated. This happens for periods of couple of minutes, and then gets fixed without doing anything.
This go back and forth along the day.
Please help
We need diagnostic info and also some reproduction steps
I too ran into this one the last couple of days. I suspect the "bug" might be Metabase having to do more lookups on joins than it can really handle efficiently. Let me describe our structure and issue:
We have a monthly sales file for books, the common key between the sales table and the title metadata table being the ISBN. We are building a table that gets the net units and dollars for the first year of a book since publication, then years 1-3, 1-5, 1-10, and finally 1-20. All of these are organized in a table with the ISBN as the key, then the publication period, the 1 year period, followed by the 3 year and later (if applicable).
On our dashboard, we have filters to select by various book attributes, for example binding, publication date range, marketing color code, and so on. In order for people to be able to select the filters they want, the sales table joins the ISBN for the titles table. We get phantom duplicates (125 records extra out of a total 11,710 total in the table), when we have five additional joins turned on. This is to allow the users to view the description of the pertinent field, rather than having to remember a code. So the editor drop-down will show the editor code as well as name, same for the series and primary subject.
Where it started going wonky is when I added the secondary subject codes, of which there are two. Both originate in a common subjects table. So I was having Metabase do two lookups to the common subject table. Thinking that might be the issue, I cloned the subject definition table so as to have code 1 lookup the first subject table and code 2 to the cloned version. The problem persisted. After removing the second subject lookup, the number of duplicates went from 125 to 81. When I removed both of these joins, the issue went away and I got the correct number of records.
So it seems that there is a bug if there are more than 3 joins from an already joined table, secondary joins, I suppose you could call them.
Hope this helps.
P.S. I solved the immediate problem by adding the subject code descriptions to the main title file so it won't have to look up the subjects table anymore. Not exactly best practice according to relational database theory, but I figure since this is a reporting, rather than transaction processing oriented database, if we have to bend the rules a bit for Metabase to work properly, as the saying goes, "ya gotta do what ya gotta do." 