I can’t come up with a good use case for using the combined CreateAndExercise command. This would just create an ephemeral (if the choice is consuming) contract to execute some choice logic, but since I’m the only signatory on there I’m limited to what I can do. And usually I could just put that logic onto whatever contracts I’m affecting and execute it atomically. In case of long-lived role contracts, I wouldn’t want to bundle the very first create + exercise so that it’s a different command than subsequent exercises.
Can anyone explain what the thinking was when this got added? What are typical usage patterns where it makes sense to use CreateAndExercise?
You might find the original GitHub issue #382 useful. The basic idea is that this sort of simulates RPC into DAML. (i.e. “callable updates”).
For example, let’s say you have some logic in DAML that calculates business days. You don’t really want to duplicate this piece of code into your application as well, but you also might not want to run a full blown engine in your application either (this would anyway only work if you were to run on the JVM). So what you can do is wrap this DAML function into a consuming exercise, return the result of the function as the exercise’s result, and send a CreateAndExercise command.
Now, one could argue there are obvious ways to improve on this.
Don’t create a new contract for each function invocation. Create a single “Logic” contract that you can lookup by key and call non-consuming exercises on it.
Introduce a “non-committing mode” for commands that only runs the DAML interpretation in the Ledger API Server, but never sends the transaction to the Ledger. While this would still consume resources on the Ledger API Server, it wouldn’t pollute the Ledger with irrelevant transactions. This idea has come up a few times, but not with enough “ooomph” to prioritize implementing it
