From what I can tell from the candid spec the query and oneway modes can both be used on a function.
Query: No state change, get data
Oneway: Fire and forget
It seems there is opening for more modes in the future, but I want to focus on these
Working on the .NET agent and I just want to make sure I have everything clear.
With both of them together does it make sense? Query is generally for getting the current state or some derived info. Oneway is for fire and forget, so no returned data. Would a use case be that it might trigger other queries like with composite queries, or will that have a different mode.
If there really isnt a use case, Im thinking of just going with: If there is a oneway flag, then ignore if its a query or update, just invoke a call http request.
You cannot have both query oneway at the same time. oneway assumes it’s an update call. For query method, you don’t need to await, so it doesn’t make sense to “forget”. With the current spec, you can assume each method can have at most one annotation, either query or oneway. When the annotation is empty, it’s update.
1 Like
Thanks for clarifying @chenyan
Question about that though on a technical level. Where is that constraint where you cant have both at the same time? In the spec it shows <funcann>* in many places and I dont see any explicit restriction on that. Is that just from the IC side of things that query and oneway are exclusive?
Also looking into some of the candid encoding I have made, it does assume that modes is a list, but right now query and oneway are the only options
Correct. The spec doesn’t exclude having both annotations. But at the IC platform level, we only have query and update methods. oneway is simulated by giving no callback for update calls.
query call doesn’t change the state, and if you don’t want to see the return result, why calling the query method? That’s why, in our implementation, modes is a list, but it takes at most one annotation.
1 Like