So, I’m trying to understand how to properly use Transaction.Start and Transaction.End nodes in my graphs so that the order of actions is accounted for.
Here’s my sample where I want to make a sheet first and then place a view on it. But as it clear to see it’s not working because the nodes to collect sheets don’t see the sheet that I just created. Can somebody please once and for all explain how does this works and how to run transactions in desired order?
The transaction nodes aren’t really doing anything for you here. Most of the time you don’t need them because the nodes handle the transactions required by the Revit API themselves.
You have two parallel processes, so you don’t have control over what gets executed first. One way around this would be to use a waitfor strategy to link the two parts
Dynamo creates a transaction, does an action, finishes the transaction and tidies up when you run the graph, so mostly you don’t need to worry about it.
But there are occasions where a transaction has to be completed before the next bit of the graph can run… Perhaps a view must be created and the transaction completed before a new transaction is allowed to edit it? That kind of thing…
Other people can probably explain in more depth than me
@Thomas_Corrie you are right for as far as I can see. But wait for is confusing to grasp my puny mind around when it’s called that way. So, for myself, I use List.Create where the IN[0] is with the next transaction and the IN[1] is with the previous, and the I just use the output at index 0 (order here isn’t of matter). It’s the same thing but, this way I understand beter that to set order you only need to chain the graphs together.
@SeanP this is just an example; the question was about the order of transactions as a whole.
@AlexanderBerg, yes you’re right, it’s the same thing. The only advantage using design script is it can be all in one node but it’s only a small benefit
I understand it was just an example, as was my reply. Although @Thomas_Corrie comments that the transaction nodes aren’t needed here, but based on your “example” graph, that is exactly what is needed. Every change inside the Revit model must be within a Transaction, and when a graph run in normal mode, only one transaction is used. Unfortunately the sequence of the graph nor when an element is created can be controlled without the use of wait type nodes and/or transaction nodes. There are even many times when you have parallel sides of a graph like this one that a wait (or list) node is not enough to guarantee the order you want and the transaction nodes have to be used. With my example, I was illustrating that the results of the Transaction.End node should be supplied to the Transaction.Start node to use the newly created elements further in the graph. You do not need to use them to start or end nodes as you had them placed. I like to think about the transaction nodes as when you would switch and do a different manual comment in Revit.
First Revit Command or Creating the Sheet in this case (Base Dynamo Transaction)
Second Revit Command or Placing the View (Comment or End First Transaction and Start the next)
This allows the Revit model database to be updated with the sheet so the views can be placed. Depending on which actions you are trying to complete, wait nodes are not always enough and therefore the transaction nodes and/or python nodes which use manual transactions or Sub-Transactions can really streamline a graph.
@SeanP You’re correct that simply chaining nodes won’t do anything. That is exactly why I started the topic about Transactions nodes and not chaining actions with ‘wait for’ nodes.
Nevertheless (you state the same thing I believe) nodes still need to be chained with the transactions nodes in between for a script to act as a multiple scripts and execute actions based on the result of previous executions within the same graph. The order is then give by the chaining.
With this in mind, I made it work and this is the order of actions as I would imagine.
If I remove the second transactions sequence (node 9) then the script fails because despite the fact the the first transaction sequence (create sheet) is excluded in it’s own start and end nodes, there is a sort global transactions that executed parallel to the one of sheet. That’s why if I remove node 9 the script fails. It’s not excluded and so it’s can’t see the sheet that just was created.
I’m not the developer so chances are that I’m wrong. But I still state what I think so that the devs would finally correct us and say how the order is actually executed.
