Best Of
Sandbox and Virtual Datasets: Virtualize on the Source or The Target? Seeking Opinions.
Virtual Datasets are very helpful when implementing Sandbox. But where should they reside, on the Sandbox source instance or the target instance?
Since the release of Sandbox, the recommendation has always been to put materialized data where users will consume it to ensure best performance. If the source instance is a development instance and the target instance is a production, we materialize data on the target and virtualize on the source as needed.
However, multiple recent use cases seek to do the opposite. The logic surrounds better governance. The source as a dev instance will have only a few domo users who are vetted for qualifications before allowed access. They have wide discretion for creating content on the source. The target as a prod instance is where most users access domo and they can only view and consume data. Very little to no allowance is given for the creation of content on the target. You can better control the content on the target via virtualization. You can build dataflows as needed on the source and virtualize the output only the target. Pages and Card are promoted on the target and use the virtual datasets. There may be some need for dataflows on the target, but they would be an exception and only created via Sandbox promote.
This appeals to customers that have to deal with a less governed environment that's resulted in an overabundance of dataflows and datasets, many of which are redundant. By controlling the data via virtualizations dataflow restrictions on the target, a much cleaner production environment occurs.
The tradeoff to this approach is performance. The question is whether that performance difference is tolerable.
RobB
Re: Get MySQL on latest version
@BSovers Sorry for any confusion, this is not tied to consumption at all. The SQL Tile is still in beta as we are actively receiving feedback from beta testers and making changes based on that feedback (along with fixing some bugs and making sure the desired features are completed in the tile). It's a very complex feature, and we're taking our time in beta to make sure we're putting something fully baked out to GA. That being said, we've broadened the beta significantly, so if you'd like to join the beta program we could add the tile to your instance.
Re: the flavor of SQL, it is its own Magic-specific syntax. It accepts much of MySQL, much of Redshift, as well as just general ANSII-standard SQL. One notable thing that is not currently available in the tile is window functions (those will come as a follow-on). We did not want to hold the tile back until we got analytic functions, though, so those will not be in the first release. We will have documentation that gives insight into the SQL functionality for the tile, but if you are looking for a super-set of functions that are available in the tile today, you can look at the functions available in the formula writer in the Group By tile (it's a superset of functions from the Formula tile + the aggregation functions from the Group By).
Let me know if you have further questions, or would like to join the the beta for the SQL Tile.
Re: Domo Everywhere .env file
Here is some thorough documentation I put together to help people with understanding how to get developer credentials from Domo (there are screenshots to lead you through the whole process).
https://docs.clearsquare.co/private-embed-default
Re: Domo Everywhere .env file
Those are unique to each user in your instance. To create a client ID and secret you need to login to https://developer.domo.com/manage-clients and create an API Client (Client ID and Secret)
As for the Embed ID, that will depened if you're embedding a dashboard or a card. You can select under the Share menu (box with arrow coming out of the top in the upper right on the card or dashboard) and select Domo Everywhere > Embed Dashboard (or Card). This will then allow you to select either public or private embed and give you and Embed ID to put into your .env file.
Re: Stacked Bar from this dataset config?
To transform your dataset, use Magic ETL.
Setup selected columns.
Add an Unpivot Tile. Drag the Unpivot Columns tile onto the canvas.
Unpivot Columns: Select budget, forecast, and actuals.
New Column for Key Names: Enter Category.
New Column for Values: Enter Value.
This will turn the three columns into two: Category and Value.
Re: Trying to show Churn (%) as a percentage and Churn (#) as a regular number
this is awesome thank you so much
Re: Drill Down issue
@shreeyab Here are a few things to check if your drill path is not working as expected:
- Apply the same filters in the Data tab of the dataset to see which rows should be included in the drill
- Be sure that you are clicking on a dimension when you drill, not the measure, since that field is what is used to filter the drill path
- Verify that you are not aggregating any fields in the drill if you want it to show a detail view
- Check that there aren't any conflicting filters on the top level and drill views within Analyzer, since that could potentially exclude necessary data
Re: Drill Down issue
Is your top level card a Pivot Table? Where are you clicking exactly to drill down? Do you have any filters on the top level card that come from Beast Modes rather than actual values from the dataset? These things can all affect how drilling works and yield different results. Something else that has often caused me headaches is that if your org has Fiscal Calendar enabled you need to ensure both the top level card and the drill path card have the same setting for it (either to use it or not), otherwise the drilling goes awry.
Re: Combining Multiple columns into one column using beastmode
That method didnt work, but it did give me an idea that did. I was overthinking it. Instead of making the unit types as headers I made them their own column and then used a quick filter to only show the rows that matched the specific unit types i wanted.