AdminTom
(Product Manager, MongoDB)
My feedback
-
1 vote
An error occurred while saving the comment -
1 vote
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
Hi Rob -
Charts has been tested extensively on Chrome, so this is not a widespread browser compatibility problem, but likely something more nuianced for your setup. Do you have any browser extensions or proxy servers that could be impacting the content loaded into the browser? Is there anything else potentially unusual about your environment?
Tom
-
1 vote
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
Thanks for the suggestion Gabriel.
Just to make sure I understand the request: currently it is possible to add calculated fields (which can be used for things like ratios), however these fields are calculated per-document. So I think you want something like calculated fields that apply to the encoded/grouped values, for example on the total values from all documents?
That's a fair feature request. If you need this now there is a workaround which is to pre-group the data in a pipeline, e;g:
[ { $group: {
_id: {}, totalCurrent: { $sum: '$currentAmount' },
totalRenewed: { $sum: '$renewedAmount' }
}]...and then you can calculate the ratio using a calculated field, or a separate $set stage in the pipeline.
-
2 votes
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
Hi Robert, are you referring to the chart builder? While we do only have a finite amount of space in the dropdown, you can see the full collection name in the tooltip that appears to the side.
-
1 vote
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
Hi Matt -
Could you please elaborate on this request? We already show a loading spinner when the chart is refreshing due to a filter change. Is the issue that it takes a couple of seconds before we start loading? We do this deliberately in case you are still modifying your filters, but if this is the cause of confusion we can look into better UX treatment.
Tom
-
6 votes
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
We're planning on starting work on Dashboard Embedding in a couple of months. This will let you embed all charts on a dashboard in one go, and won't include the Charts branding.
-
2 votes
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
We're actually planning on getting rid of data sources altogether, which will eliminate the need to "manage them". Basically the idea is you will be able to point a chart at any collection without needing to explicitly create a data source abstraction over that collection first.
-
3 votes
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
Thanks for the suggestion Daan. We are looking at making changes to data sources that will address this.
-
1 vote
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
You should be able to use the Convert Type option to convert the array to numbers. Any non-numeric values will be converted to null, and the numeric accumulates should work.
-
5 votes
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
Thanks for the suggestion Arnold! We're looking at how best to handle this scenario.
Rather than tie it to filters, we were thinking of adding a new method to the SDK that would let you do something like:
chart.setField("startDate", new Date("2020-09-07"))This would result in the requested value being added early in the agg pipeline for each document, i.e. with:
{ $addFields: { startDate: ISODate("2020-09-07") } }Then if you wanted to leverage it in your own query, you could simply refer to "$startDate" and it would contain the value set from the code.
Let me know if you think this will work.
-
41 votes
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
Note that if you click the Zoom button on any chart, it does go into a responsive mode. This can be useful when viewing dashboards on a mobile device too.
I've been reluctant to make the dashboard view responsive by default, as many charts require a specific size to look good, and having the charts change size based on the user's browser could mean the author's preferred chart dimensions wouldn't apply.
How would people like this to behave? Would a separate mobile-friendly / responsive view be enough, or should the default dashboard view be responsive?
AdminTom
(Product Manager, MongoDB)
shared this idea
·
-
6 votes
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
Thanks Caylan - this is definitely on our radar - will probably look at Number and Gauge charts first, and then consider how to apply it to other charts later.
-
2 votes
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
Hi Johan - while you can only have a single filter document on an embedded chart, the document can be as complex a filter as you want, e.g:
{ foo: 1, bar: 'x', baz: { $gt: 4 } }
....or even
{ $or: [ { foo: 1 }, { bar: 'x', baz: { $gt: 4 } } ] }
Can you explain a scenario where this doesn't give you the required flexibility?
-
3 votes
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
Hi John, can you give an example? When we have aggregation channels it means the chart expects a number (e.g. to show the length of a bar). In the case where you only have one document in a category, an aggregation like Sum, Min or Max will all return the raw value.
-
4 votes
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
Thanks for following up. So you are correct that verified signature embedding never used the filter whitelist - this only applies to unauthenticated and the new authenticated embedding. While we are deprecating verified signature embedding (since authenticated is generally easier and more powerful), we won't be disabling it any time soon and we'll make sure we support the document-level whitelisting you require before we do this. So it is fine to keep using verified signature in the meantime if this has the features you need.
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
Thanks for the suggestion. We haven't ever changed the behaviour here - it was always necessary to whitelist each exact field you want to use. However I think this is a valid feature request for people that use dynamic schemas.
In the meantime, you could work around this by using the Verified Signature embedding model which does not use whitelists.
-
45 votes
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
Hi Christopher - neither for now. You can already safe a chart as a PNG by right-clicking on it and using the browser menu. More options for exporting charts and dashboards will be considered in the future, so please vote for this and/or comment with more info on the scenarios that matter to you.
AdminTom
(Product Manager, MongoDB)
shared this idea
·
-
558 votesAdminTom
(Product Manager, MongoDB)
supported this idea
·
-
32 votes
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
Note that you can already choose a dark theme when rendering embedded charts. Allowing the main Charts app to use a dark theme is something we're looking at doing soon.
AdminTom
(Product Manager, MongoDB)
shared this idea
·
-
12 votesAdminTom
(Product Manager, MongoDB)
responded
Timeout was increased from 60 seconds to 90 seconds. There aren’t currently plans to increase it further, but keeping the issue open in case it needs it be looked at again in the future.
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
In the latest cloud release we have increased the query timeout from 60 to 90 seconds.
AdminTom
(Product Manager, MongoDB)
shared this idea
·
-
6 votes
An error occurred while saving the comment AdminTom
(Product Manager, MongoDB)
commented
Hi Brian -
That's a good idea. We will be looking at enhancing binning next year so I'll see if we can do something along those lines.
In the meantime, it is possible to achieve what you're looking for with a calculated field. For example you could create a field with a definition like this:
{
$switch: {
branches: [
{ case: { $lt: [ '$age, 18 ] }, then: "0-18" },
{ case: { $lt: [ '$age', 30 ] }, then: "18-30" },
],
default: "30+"
}
}One thing to consider is that the resulting labels will be strings, so you'll need to choose names that put them in the right order with an alphabetical sort.
Thanks for the feature request. While I agree it would be ideal to support more customisation for date binning in the product, it is possible to get what you want by using calculated fields:
1. Create a new calculated field called "weekDay" with the following formula, replacing "yourDateField" with the name of the field you are using:
{ $dayOfWeek: "$yourDateField" }
2. Create a new calculated field called "spanishWeekday" with the following formula. Note that I am translating the numbers from the first calculated field into Spanish but also prefixing with a new number to influence the sort order.
{
$switch: {
branches: [
{ case: { $eq: [ "$weekDay", 1 ] }, then: "7. Domingo" },
{ case: { $eq: [ "$weekDay", 2 ] }, then: "1. Lunes" },
{ case: { $eq: [ "$weekDay", 3 ] }, then: "2. Martes" },
{ case: { $eq: [ "$weekDay", 4 ] }, then: "3. Miércoles" },
{ case: { $eq: [ "$weekDay", 5 ] }, then: "4. Jueves" },
{ case: { $eq: [ "$weekDay", 6 ] }, then: "5. Viernes" },
{ case: { $eq: [ "$weekDay", 7 ] }, then: "6. Sábado" }
],
default: "n/a"
}
}
3. Use the new "spanishWeekday" field on the category axis of you chart, and choose to sort by Category in ascending order.