The Product Idea boards have gotten an update to better integrate them within our Product team's idea cycle! However this update does have a few unique behaviors, if you have any questions about them check out our FAQ.

Alteryx Designer Desktop Ideas

Share your Designer Desktop product ideas - we're listening!
Submitting an Idea?

Be sure to review our Idea Submission Guidelines for more information!

Submission Guidelines

Options for removing metadata Source information

The Source field of the field metadata is very useful, but has some problems.

 

  • It is repetitious. A long connection string repeated for many fields from the same source can bloat the size of the workflow above 10 MB, and when removed is around 0.5 MB.
  • It exposes sensitive information about a company's infrastructure, such as server names, ports, user ids, and proprietary data structures.

I first started paying attention when we found a user's password in the metadata because they had passed it as a string to the Dynamic Input Tool (separate Idea submitted for that - LINK). Then when I had to share an App with the Alteryx Support team for support with an issue, I thought to check the metadata, and I noticed that the file was too big and was exposing information that I would not normally share with another company.

 

I'm not sure how you want to handle this, but here's some thoughts:

 

  • Default the Source field to 'off' and provide users the option to turn it 'on' in the workflow/app settings.
  • Provide a mechanism to strip the 'Source' field at time of saving or exporting the workflow.
  • If nothing else, provide education to users on the implications of including this information in the file.

 

Thanks for listening!

 

Cameron

12 Comments
piotrzawistowski
8 - Asteroid

Hi Cameron,

 

Thanks for publishing this problem. I have the same issues - some sensitive data can be seen i.e. in Alteryx Gallery.

conn_str.png

 

From my point of view it is big disadvantage of the server. 

 

Hi Alteryx Team,

Do you have it on the roadmap?

 

Best,

Piotr

patrick_digan
17 - Castor
17 - Castor

+1 I like your ideas here

Scott_Snowman
10 - Fireball

Yes, please implement this! Just found a macro we are using that is over 11MB in size because the Source is being set as a long query string for 20 fields on multiple tools!

Ringo
6 - Meteoroid

There has to be some way to prevent this meta info from being added. For as far that I could find out, this meta info causes our output data set to increase in size from 30GB to 69GB.

Ringo
6 - Meteoroid

We realized that part of the size issue was having a lot of fields set with the field type v_wstring when v_string was the better/smaller type that should have been applied.

 

Although the above helped reduce the earlier mentioned dataset, the following new dataset had a massive increase again although the overall number of records only increased marginally. We also removed one large sized field, so we should have seen about the same size dataset as before, if not smaller.

 

We really need someone from Alteryx to take a look at this matter.

Colgan
ACE Emeritus
ACE Emeritus

One of our users had a 110MB .yxmd all due to the source meta data.

Hiblet
10 - Fireball

A +1 for this.  I have a flow that pulls some data from a database with a query with a large IN conditional statement.  This makes the metadata huge.  Making any change to the flow involves a 30 second wait whilst the XML is reviewed for changes.  I don't find the source metadata that useful, yet it has the highest operational cost whilst editing the flow.

pachoe85
6 - Meteoroid

Hi,

Is there a follow up and/or solution to this? I have a similar problem that bloats the size of my workflow due to the metadata found in an input tool

Hiblet
10 - Fireball

Making the metadata default to off, and allowing users to choose to turn on, would be extremely useful.  At worst, metadata might be best limited to a max number of characters to avoid the amazing bloating that can occur.

pachoe85
6 - Meteoroid

Yes that would be a great option to have. However, it seems that there is no way to this as of now, correct?