hyperledger
GetHistoryForKey sortable & pageable
Current Status
In one of our HLF projects, we have a blockchain network in which some assets have thousands of modifications. A client requirements specifies that they need the history of the asset presented ordered by one of the fields of the asset. For now, what we do is use GetHistoryForKey, obtain all entries and order by this field. Then, we build our pagination system on application level, which just to does some splice to mimic a pagination system. We are worried what will happen when an asset haves ten of thousands of entries.
Expected
Although I am not sure about the viability of this, it would be really helpful to have something to order the results and have some pagination, avoiding memory problems when the asset has too many transactions
Solution
No response
Please let us know if you plan to work on this.
No response
An option to consider is replicating relevant ledger data in an off-chain data store, where you can more efficiently query and present the required information. The off_chain_data sample in the fabric-samples repository contains some discussion and example implementations to achieve this.
But what's the point of storing information in an offchain? One of the keys for blockchain is that data is inmutable. Using an external database will not guarantee inmutability and you will have data by duplicated in multiple datasources and models. HLF should paginate data before sending it to its client...
Thank you for bringing up this issue. I’ve encountered similar challenges when working with Hyperledger Fabric, particularly regarding [mention any specific related issue you faced]. It would be helpful to get more clarity on whether this behavior is expected or if there are any recommended workarounds. Have the maintainers considered addressing this in future releases or providing additional documentation? Any insights would be greatly appreciated!
- State in storage (leveldb) key-value can be retrieved or sorted only by primary key. In order to be able to sort values differently, it is necessary to create keys by the field of interest when saving the value. For example: you have an entity car, car brand and car owner. Then when adding a car you should save it like this: Then we can sort them by 2 fields.
stub.Put(alice/car/id, car)
stub.Put(opel/id, car)
-
historyDB saves your records with this key historyKey = key+number_of_block+number_tx_in_bock and you can sort only by this primary key (historyKey).
-
Adding additional secondary indexes is the responsibility of the chaincode developers.
-
How I would approach solving your problem.
- disable history db
- create a custom historical key system (+1 secondary index)
- add as many secondary keys as needed for sorting and pagination.
