Inherited field renaming

[shashi_lingaiah]

If we rename a field ‘X’ to ‘Y’  in the alteryx module, the renaming is not inherited by all the tools using that field in that module. The tools which are still using the old field name ‘X’ will fail until they are configured to use the new field name ‘Y’. Most of the tools I have worked will inherit the field renaming.
 
It would be very helpful if the renaming is propagated to all the tools in the module using that field name. 

[ephij]

Please please please.  So much time spent either documenting old field names in a workflow because the source changed and I didn't have time to go update all the tools or obsessively cleaning everything up tool by tool with the renamed field.

[SeanAdams]

This is a capability (identify unique fields, and change them throughout the canvas if renamed) that has been discussed quite a lot in many different forums - and I think that there's a few ideas posted on this topic too.

In many ways - this would then mirror much of the functionality of many development tools - and by keeping explicit record of a unique field ID, it would also open the way to deeper optimizations of the workflow (which is an idea that @JoshKushner floated)

Adding @AdamR_AYX

Out of interest - this is also a necessary capability to do field-level lineage tracing from outside Alteryx in a meta-data tool or a catalog.   For example - the standard regulatory need to answer the question "where did this value come from - trace it back to source fields"

@dataMack 

[SeanAdams]

HEre are a few related ideas

https://community.alteryx.com/t5/Alteryx-Designer-Ideas/Inherited-field-renaming/idi-p/1501

https://community.alteryx.com/t5/Alteryx-Designer-Ideas/Dynamic-Rename-Fields-Available-Without-Runn...

https://community.alteryx.com/t5/Alteryx-Designer-Ideas/Change-to-Field-Name-Impact-to-the-Workflow/...

https://community.alteryx.com/t5/Alteryx-Designer-Ideas/Update-field-names-across-entire-workflow/id...

https://community.alteryx.com/t5/Alteryx-Designer-Ideas/Trace-Field/idi-p/91452

[JoshKushner]

This could potentially be resolved with pointers to fields stored in XML "memory" so that each time the field is referenced it would point to the "memory" and include an alias if necessary (although this is it's own host of complications).

This would require the XML behind an Alteryx canvas to fundamentally change.

@NeilR, @Claje, @

[Claje]

I think that this feature could be developed without necessarily requiring significant changes to the XML that makes up an Alteryx workflow.

Conceptually, a feature like this needs to be able to look forward from a change in a Select tool, and check for the historical field name to perform updates to tools downstream as appropriate.

While what I am about to propose is not at all how I would like to see this implemented, i think you could build a proof of concept Alteryx App which performed field name edits downstream by utilizing the connection information stored in the XML today.  I'm thinking something like three chained applications:

Step 1 loads the selected Alteryx workflow, and gets a list of all Select tools in the workflow.

Step 2 lets the user pick which Select tool to apply updates from, and then loads the fields in that tool.
Step 3 lets the user pick which field to apply an update from, and what to change the name to.  Then it runs through the entire workflow selected in Step 1 and updates all field references in the XML and formulas.

Obviously, since the Alteryx engine is capable of identifying downstream impacts from a field name change, I think it should have the ability to do a lot of this more effectively than a brute-force solution like the above proposal.  It should be as simple as storing the old name in memory for the workflow validation, and upon finding a missing reference (or references) which matches to the name in memory, prompts to ask if you would like to update this reference.

[JoshKushner]

If I understand the proposal correctly, think this is a great idea and
could update the back end XML in real time while working in a workbook. --

Josh Kushner

[SeanAdams]

Hey all,

Check my thinking - but as far as I'm aware, the one gap that would need to be closed for the computational approach that @Claje and @JoshKushner are suggesting is that many tools don't store the full field list.

For example - the select tool only stores changes or subtractions from the field list.

So - agree with your thinking - and the first step is to parse the XML and persist all the fields in each tool.

[dataMack]

I like the discussion in this thread, but agree with @SeanAdams that given the related variants to this idea that have already been discussed, AYX should consider solving it in a broader application level way outside of just enhancements to the Select tool.

[Claje]

I would hesitate to suggest redesigning the metadata of the yxmd workflow itself to persist field information tool by tool as I think it would significantly increase workflow sizes.  I can't attach workflows here, but I've included a few screenshots of a workflow size proof of concept.

Generate 1000 rows, cross tab to create fields

I saved this flow twice, once with no changes in the Select tool, and once changing the data type from Double to Int32 for all 1000 fields.

As you can see in the below screenshot, the second flow (with 1000 field changes) is almost double the size of the first.  Persisting this much extra information on all calls seems like it would dramatically impact performance based on what I have seen in large or complex Alteryx flows today.

Since the Alteryx engine can already identify which tools break when upstream fields change, my theory is that the engine could be updated to support pushing these changes downstream dynamically without dramatically increasing stored metadata.  The reason I proposed a "workflow proof of concept" is because I'm assuming that the engine itself is performing similar checks of all metadata and connection info within the workflow, and so the same concept could be applied for all existing tools more easily.

[SeanAdams]

Agree about the size @Claje - the trade-off is that by using this shortcut, it becomes impossible to do a full trace on all fields to look for lineage at a field level.

For example - the question "where did this output field come from" becomes very difficult if we're not fully capturing all the fields.

I'd take the trade of a doubling of an alteryx file size (given that they are so small - in the order of kilobytes), if it gave us this kind of trace and lineage on large data sets (often in the order of MB or GB)