Be able to disable fields

Hi,

what is the reason for wanting to keep them in the interface but not have them in the physical database? I don't think I have ever run into wanting to do something like this, so I am really curious about the reason.

If you want to recreate deleted transformations later, just mark the version with a version note and reopen it later to copy the syntax if that is what you need.

In general when phasing out MDW data I would clone the table and remove what you want from the new copy while guarding the old one. You can then switch over to the new and eventually remove the old. 

There are all sorts of potential dependency, mapping and lineage issues I would foresee with this. So I suspect this would be rather complex to make happen.

For me this is mainly a development and debugging use case. Not so much a production lifecycle strategy.

When you’re building or refactoring a table, you don’t always know yet whether a calculated field is truly obsolete or whether it might still be needed later. During that phase it’s very helpful to be able to temporarily switch off a field.

It will help me to:

• Isolate errors by disabling parts of the transformation logic and re-running the table
• Reduce noise in the valid model while keeping the logic visible for context
• To avoid fully deleting logic that you may want to re-enable after some testing or discussion

Version notes or cloning can work, but they’re heavier-weight and less practical for quick iteration. Disabling a field would be a lightweight, reversible action during development, while still keeping the transformation readable in the TX view.

Regarding the potential dependency, mapping and lineage use, I will leave that to the TX-developers to decide. Maybe a handling like a 'raw’ field could be used. It will only exists in the area it is, and only in that specific table. But not outside the table.