What is automatically updated when renaming a dataset?

Hi Everyone,

 

We are currently in the process of renaming all of our datasets and dataflows using a new and improved naming convention.  About halfway through I had the prophetic thought of "this dataset is referenced in x many dataflows, I sure hope those all update..." luckily, since the flows have run without issue I think the crisis has been averted (reminiscent of Y2K).

 

My question is - in MySQL data flows what updates and what doesn't? When I looked at a dataflow utilizing one of the renamed data sets I found that in the "Input DataSets" at the top and the "Output DataSets" at the bottom both update automatically.  Interestingly, the "Available Inputs" and all table references in my individual transforms still have the old name for the input dataset.

 

Is there any way to change these? Will they change on their own? Or from now on will the name of the dataset and the display name remain different?

 

Thanks,

Austin

Best Answer

  • AS
    AS Coach
    Answer ✓

    You've stumbled on one of the quirks of dataset names.

     

    When you add an input to a dataflow, behind the scenes Domo is creating a JSON object and the original name (the name of the dataset at the time you added it as an input) is stored in the name/value pairs. Whenever the dataflow references the input it looks for the original name.  If the name changes on the dataset, dataflow still looks for the original name, which is why your dataflow still runs.  

    If you updated the text of the altered dataset name in the SQL, it would break.  If you were to remove the dataset from the input list and add it back, but not change the SQL, it would also break because the "new" dataset doesn't have the same name as the original name that the SQL is referencing.  

     

    It can be confusing to have a dataflow reference a dataset name that doesn't appear to be in the list of inputs.  But luckily you can leave the SQL as-is, if you want, and it'll run fine.  Or you can go through the work of updating the SQL.  That's what I usually do if I remember to and know what dataflows reference my altered inputs.  That last bit would be easier to know if Domo would display, like how many cards are used by a dataset, how many and what dataflows use that dataset.

    Aaron
    MajorDomo @ Merit Medical

    **Say "Thanks" by clicking the heart in the post that helped you.
    **Please mark the post that solves your problem by clicking on "Accept as Solution"

Answers

  • AS
    AS Coach
    Answer ✓

    You've stumbled on one of the quirks of dataset names.

     

    When you add an input to a dataflow, behind the scenes Domo is creating a JSON object and the original name (the name of the dataset at the time you added it as an input) is stored in the name/value pairs. Whenever the dataflow references the input it looks for the original name.  If the name changes on the dataset, dataflow still looks for the original name, which is why your dataflow still runs.  

    If you updated the text of the altered dataset name in the SQL, it would break.  If you were to remove the dataset from the input list and add it back, but not change the SQL, it would also break because the "new" dataset doesn't have the same name as the original name that the SQL is referencing.  

     

    It can be confusing to have a dataflow reference a dataset name that doesn't appear to be in the list of inputs.  But luckily you can leave the SQL as-is, if you want, and it'll run fine.  Or you can go through the work of updating the SQL.  That's what I usually do if I remember to and know what dataflows reference my altered inputs.  That last bit would be easier to know if Domo would display, like how many cards are used by a dataset, how many and what dataflows use that dataset.

    Aaron
    MajorDomo @ Merit Medical

    **Say "Thanks" by clicking the heart in the post that helped you.
    **Please mark the post that solves your problem by clicking on "Accept as Solution"
  • Thanks for the details!  Its helpful to understand the back end processes - and thats actually a great way to handle it (short of automatically updating all the SQL).

     

    I think rewriting all of the SQL will go under the "Once we have a summer intern..." column.