> Join peers to a new channel should be easier than dealing with orderers. The point is not to migrate all the data over. You want to start fresh and leave the old data in its own channel. Doing migration will defeat the purposes.
Unfortunately we need the data from the past. So leaving it in the old channel means modifying the chaincode significantly, so that it not only looks it up in the current channel state DB, but also in all the historical channels. Basically making the chaincode aware of the presence of historical channels and all the history of the migrations.
This effort is comparable to the effort of migrating the data to the new channel.
Drawbacks (compared to the ledger pruning):
- the channel jump/migration must be synchronised for ALL the nodes, which is an admin nightmare in case of independently managed peers/orderers
- we have to make chaincode aware of new migration every time we want to "prune" the ledger DB this way
- it is very application-specific. We have to solve it separately for every application we have / will have.
- can be implemented with the current codebase, no need to change the existing code.
When it comes to us, we prefer the more general solution, mostly because of the complexity of the admin task to synchronise all independent peers when doing the jump to the new channel.
// Vitalii Demianets @ norbloc AB