-
Does deleting a marble re-write history? How is this not breaking the blockchain ledger?
-
What is with the required input arguments for the marbles chaincode?
It does not re-write history. "History" would refer to the ledger, which can not be re-written under normal circumstances. The "delete" transaction is a regular transaction that gets recorded into a block in the ledger. Therefore the marble's creation and activity remains in the ledger unchanged, forever, even after a "delete". However the state of the asset did change. The ledger and the world state are different things. The ledger contains the historic actions to the chaincode and channel (transactions). While the world state is all the asset data at a specific moment of time. Think of it as the combined result of playing back all transactions. When we created a marble, we appended the create transaction to the ledger, and added the marble to the world state. Like-wise when we delete, the delete transaction is appended to the ledger, and the world state is altered to remove the marble.
The marbles chaincode requires a single integer as an input. This is purely for demonstration reasons to show how its possible to pass inputs to a chaincode during its instantiate. The actual number you provide to marbles is meaningless, go nuts.
The latest and greatest marbles already does this! Checkout the fc wrangler
files: high_availability.js and index.js. The code snippet below shows that when an invoke fails, we call ha.switch_peer()
to send the same call to the next peer. Remember that the SDK is configured to send requests to specific peers, so all we have to do is change this peer. You may find the comments in the code below helpful.
Note that the function ha.switch_peer()
returns null when we have looped through all the peers. The code then returns and sends the last error.
./utils/fc_wrangler/index.js
fcw.invoke_chaincode = function (obj, options, cb_done) {
invoke_cc.invoke_chaincode(obj, options, function (err, resp) {
if (err != null) { //error with the request, try again
if (ha.switch_peer(obj, options) == null) { //try another peer, if we have one
logger.info('Retrying invoke on different peer');
fcw.invoke_chaincode(obj, options, cb_done);
} else {
if (cb_done) cb_done(err, resp); //out of peers, give up, send err
}
} else { //success
ha.success_peer_position = ha.using_peer_position; //remember the last good peer
if (cb_done) cb_done(err, resp); //call callback, send good result
}
});
};
Great, I recommend that everyone starts with a local network. Lets get going .
It's called the Fabric Client Wrangler. It is simply a wrapper around the fabric-client SDK module. ie it gives me a slightly friendlier interface to the SDK. It is generic and reuseable for your own adaptations. It is not a required component of a node.js -> Fabric application, but I feel it helps.
Yes. Open an issue on our GitHub Issues. Please include as much info as you can, such as the logs you are seeing, what you were expecting to happen, etc.