This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
@jeff_reynolds It's not just you. You should post this over in the ideas section. I completely agree with your sentiment. I see a couple of key cons to the new cache input option: 1) if you were to add a tool after the input tool and cache it, it would not use the cached input; it would instead re-run the query. I have posted an idea here that would address this. 2) as you pointed out as well, I have some workflows with 10+ inputs where I've checked the cache option. Previously, my first run would take a while but then every run after that would use cached inputs and allow for easier development. Now, it appears that I would have to go through and click cache and run my workflow for every tool every time. I have posted an idea here that may address this.
I feel the same. I thought the new version would be much easier to cache and run from any point. However, removing the cache function on input node is a big mistake. I have to right click cache and run then have to stop the work flow and start over on the next node. Not fun.
Thank you for sharing. I did vote on @patrick_digan's idea submission. Thank you very much.
I agree here. Why would the new Cache and Run necessitate removing the Cache Data option on the Input Tool. I like the new Cache and Run concept, but it is a bit limited. Often times, my workflow has a dozen or more data sources. They also regularly have multiple branches and the Cache and Run only supports a single cache point. I get that caching too much data can cause performance issues, but wouldn't that decision be better left to the analyst?