Replies: 2 comments 1 reply
-
Sorry that I have not yet review source code but upon my first glance of |
Beta Was this translation helpful? Give feedback.
-
@mbwhite Great discussion points!
We wondered about this for the existing Java SDK and again for this one. The trouble with returning
So right now my feeling is that plain return values are more helpful as they are easier to invoke and give the calling code the flexibility to wrap with whatever asynchronous execution mechanism they prefer, for example: Proposal proposal = contract.newProposal("txName").addArguments("arg1", "arg2").build();
try {
Transaction transaction = CompletableFuture.supplyAsync(proposal::endorse).get(30, TimeUnit.SECONDS);
} catch (InterruptedException e) {
// Handle interrupt
} catch (ExecutionException e) {
// Handle endorsement failure
} catch (TimeoutException e) {
// Handle timeout
}
The idea is that the "async" variants don't block waiting for a commit to be observed on the ledger, and instead return immediately after successfully submitting to the orderer, allowing the client application to do other work with the transaction result while asynchronously waiting for the commit. There is a strong precedent for function names to end with "Sync" where they are synchronous in the JavaScript sense, rather than taking a callback or returning a Promise, so that seemed like a confusing choice for the I'm keen to hear if anyone has better alternatives for clear and concise naming.
Using
I would actually prefer if it was on the Contract, as it is in the existing SDKs. This does have the potential to cause unexpected behaviour in the existing SDKs, which is why I currently have it on Network in Fabric Gateway. The problem is that the Contract represents a smart contract, which may be the default (no namespace) smart contract within a given chaincode or one of several (namespaced) smart contracts within a given chaincode. However, there is no distinction between events emitted by different smart contracts. All events emitted by a given chaincode are tagged only with the chaincode name. So if I listen for events emitted by smart contract "A", that listener will also receive events from smart contracts "B" and "C" within that same chaincode. Often people are only using default smart contracts (so there is a 1-to-1 mapping between chaincode and smart contract) and so don't hit this issue, but it's there. I think the sensible choices are to either:
That's a good suggestion. I have raised issue #179 |
Beta Was this translation helpful? Give feedback.
-
API minutiae for some of the different sdks
async submitTx
andasync submitTxAsync
submitTx - resolves when the transaction has been committed
submitTxAsync - resolves with the commit object with async apis to get the results.. seems a bit confused...
newProposal
only time Proposal is used, to match consistency with submitTransaction/evaluateTranasction the examples show these being used for transient data... in this context wouldnewTransaction
or evennewTransactionProposal
? Understand that there might be more complex use cases.. but transient would be commonnewChaincodeEventsRequest(chaincodeid)
on the network and not the contract object?newProposal()
form that submit/evaluateTx are equivalent to?Beta Was this translation helpful? Give feedback.
All reactions