2017-07-03 22 views
1

私は、同じキー名(保存している人物の名前)を複数回使用し、すべてのエントリを欲しいスマートコントラクトを作成しようとしていましたその名前を照会するときに出力されるキー名。
超人預金者では可能ですか?はいの場合、どのようにクエリ関数を書くでしょうか
同じ結果を得るために別の方法をお勧めしますか?
私はハイパージーガーに慣れておらず、これに類似したチェインコードの例を見ていないと思っています。Hyperledgerで同じキー名で複数のエントリを作成する

+0

からのいずれかの方法を使用することができます変更の履歴を取得するには(ない場合は)私が考える一つの解決策は、引数として名前に取ると、それにいくつかのサフィックスを添付することですName.mobile_no.xのようにxは数字が追加された名前で表示されなくなるまで、ブロックチェーン内の名前を照会して同様のエントリを持つ最後の数字よりも1だけ多くなります。どんな良いアイデアですか? – Snorlaxative

答えて

1

あなたがする必要があるのは、値をJSON形式にエンコードし、指定されたキーに対してマーシャリングして格納することです。たとえば、スライスで構造体を定義し、毎回新しい値でスライスを更新/追加し、配列を作成し、元帳に保存します。

元帳からバイト配列を読み取るたびに、構造体に戻され、必要な情報で更新され、同じキーで元に戻されます。


あなたはChaincodeStubInterface

// Chaincode interface must be implemented by all chaincodes. The fabric runs 
// the transactions by calling these functions as specified. 
type ChaincodeStubInterface interface { 


// Other methods omitted 

    // GetHistoryForKey returns a history of key values across time. 
    // For each historic key update, the historic value and associated 
    // transaction id and timestamp are returned. The timestamp is the 
    // timestamp provided by the client in the proposal header. 
    // GetHistoryForKey requires peer configuration 
    // core.ledger.history.enableHistoryDatabase to be true. 
    // The query is NOT re-executed during validation phase, phantom reads are 
    // not detected. That is, other committed transactions may have updated 
    // the key concurrently, impacting the result set, and this would not be 
    // detected at validation/commit time. Applications susceptible to this 
    // should therefore not use GetHistoryForKey as part of transactions that 
    // update ledger, and should limit use to read-only chaincode operations. 
    GetHistoryForKey(key string) (HistoryQueryIteratorInterface, error) 


} 
+0

ありがとう!私はまた、変更された属性の全履歴を私の場合に有用な情報である元帳原因に含めることを望んでいました(たとえば電話番号を取る)。それを実装する方法は? – Snorlaxative

+0

私は私の答えを更新しました、GetHistoryForKey APIを使用することを検討してください。 –

+0

ありがとうございました!それは完全に問題を解決する! – Snorlaxative

関連する問題