Bug #2141
closedTrends grahs issue
Description
The screenshot is worth a thousand words.
Files
Updated by Robert Birnie about 12 years ago
Can you provide the page's source? There must be something funky in how it is building the array the graph uses.
Updated by Romain Vrignaud about 12 years ago
- File trends.source trends.source added
See attached
I have that behavior in all my trends.
Updated by Ohad Levy almost 12 years ago
- Assignee changed from Robert Birnie to Ohad Levy
- Target version set to 1.1
This is a ordering issue (where the JSON is not sorted by time).
I'm attaching a fix, but I'm unable to confirm it works (as I can't reproduce locally).
Please reopen if required.
Updated by Ohad Levy almost 12 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Applied in changeset 30bcb14580c41e8439de1cb8f3773cea77e1ae6b.
Updated by Robert Birnie almost 12 years ago
- Status changed from Closed to Assigned
- % Done changed from 100 to 50
This doesn't seem to fix it.
Updated by Ohad Levy almost 12 years ago
hmm.. since i don't have the data set to try and replicate it, can you try playing around with the queries used, from past experience, its usually a non sorted data set, which confuses highcharts.
Updated by Robert Birnie almost 12 years ago
Both my page and his has duplicates in the data. I'll go look through my database and see if there are duplicates there too or if the array is getting made poorly.
[1358420109000,1],[1358420109000,1]
Updated by Robert Birnie almost 12 years ago
Dupes in DB too
#<TrendCounter id: 744206, trend_id: 3, count: 287, created_at: "2013-01-30 09:00:10", updated_at: "2013-01-30 09:00:10">,
#<TrendCounter id: 744317, trend_id: 3, count: 287, created_at: "2013-01-30 09:00:10", updated_at: "2013-01-30 09:00:11">,
Updated by Sam Kottler almost 12 years ago
Robert just said in IRC that he was able to fix the issue by removing a duplicate cronjob. Can you confirm there is only on cronjob installed to run the task?
Updated by Robert Birnie almost 12 years ago
Romain,
Check for duplicate cronjobs. Foreman auto creates ones now in /etc/cron.d/foreman
I also create a rake task to clean up duplicates so you can easily fix this.
Updated by Ohad Levy almost 12 years ago
Robert Birnie wrote:
Romain,
Check for duplicate cronjobs. Foreman auto creates ones now in /etc/cron.d/foreman
I also create a rake task to clean up duplicates so you can easily fix this.
does it mean we miss a validation on foreman side? we can ensure that duplicated data is not imported regardless if you have multiple cronjobs?
Updated by Robert Birnie almost 12 years ago
I guess we could do an ensure unique based on created_at and trend_id.
If we did it through the model, how would we notify the user of the issue to be rectified? Crazy graphs are a pretty good notification. :D
Updated by Ohad Levy almost 12 years ago
Robert Birnie wrote:
I guess we could do an ensure unique based on created_at and trend_id.
First of all, we would ensure that the data is accurate, imho thats more important.
If we did it through the model, how would we notify the user of the issue to be rectified? Crazy graphs are a pretty good notification. :D
Secondly, we could / should log the error to the log, and in theory create a notice (we have a notice model), but even if you alert, you might end up having multiple alerts.
I would say, since this is an edge case (mis configuration) then, I would alert to the log and thats it?
Updated by Robert Birnie almost 12 years ago
- Status changed from Assigned to Closed
- % Done changed from 50 to 100
Applied in changeset 0d264ea7067c59ddd14bf702525841f92b313908.