1. 03 Feb, 2017 1 commit
    • manish's avatar
      Move Blockstorage code under /fabric/common package · 2a16532c
      manish authored
      https://jira.hyperledger.org/browse/FAB-2022
      
      
      
      This changes introduced by this CR
      - Moves the block storage code from package
      core/ledger/blkstorage to common/ledger/blkstorage
      
      - Splits the ledger_interface.go so as to move common interfaces
      and data type to common/ledger package
      
      - Moves some of the util functions to common/ledger package
      
      - Moves core/ledger/ordererledger package to orderer/ledger/fsledger
      orderer folks can futher rename/refactor this as seems suitable to them
      
      Change-Id: I759e16f00dc2ec9bb62196121083cf48eae76948
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
      2a16532c
  2. 30 Jan, 2017 1 commit
    • denyeart's avatar
      [FAB-1933] ExecuteQuery on leveldb panic · 6255f8d3
      denyeart authored
      
      
      ExecuteQuery() is not supported on leveldb state
      database.  Currently if called it will panic the peer.
      This changeset changes it to a normal error
      so that it does not kill the peer process.
      
      Change-Id: Ib9f525524c99b107b4fc3935f2d38a5657bace73
      Signed-off-by: default avatardenyeart <enyeart@us.ibm.com>
      6255f8d3
  3. 27 Jan, 2017 1 commit
    • Chris Elder's avatar
      FAB-1818 Create data wrapper for state data in CouchDB · ead6705d
      Chris Elder authored
      
      
      Motivation for this change:
      Maintain the version inline with the document, without changing the
      structure/value of the stored document.  This will prevent unexpected
      data values being returned and will prevent possible name collisions
      with document values.
      
      - Create a data wrapper for ledger JSON data stored in CouchDB.
      
      - Return the version based on block number and transaction id
      
      The wrapper will be implemented as a new key named "data" which will
      contain the JSON data for the state database.
      
      Prior to change example:
      
      "doc": {
       "_id": "2",
       "_rev": "2-8ee0c31b21ad650e5b872c0b98e59ab5",
       "version":"1:2"
       "asset_name": "marble2",
       "color": "red",
       "owner": "tom",
       "size": "25"
      }
      
       Following change:
      
       "doc": {
        "_id": "2",
        "_rev": "2-8ee0c31b21ad650e5b872c0b98e59ab5",
        "version":"1:2"
        "data": {
         "asset_name": "marble2",
         "color": "red",
         "owner": "tom",
         "size": "25"
        }
       }
      
      Change-Id: I59391ea926531c46c346fc8448e3d041ca5f3fdf
      Signed-off-by: default avatarChris Elder <chris.elder@us.ibm.com>
      ead6705d
  4. 26 Jan, 2017 1 commit
    • denyeart's avatar
      [FAB-1762] Refactor couchdb history db to leveldb. · 2c982629
      denyeart authored
      
      
      - Utilize leveldb for history of keys instead of couchdb
      
      - Single leveldb database serves all chains to optimize
        footprint (same structure as leveldb block index database
        and leveldb state database)
      
      - Block commit writes a history key for each key/value
        that is updated in a tran, in the form:
         ns~key~blocknum~trannum
      
      - History database is an index for history of key writes
        over time.  The key values are not included to reduce
        size of database.
      
      - GetHistoryForKey() finds all records starting with ~ns~key
        and returns the transactions that updated the key.
      
      - Subsequent changeset will lookup and return the txid
        and historic value from the block storage.  Client can
        then GetTransactionById to see the historic transactions.
      
      - Since history db size is much reduced, it is now enabled
        by default in core.yaml.
      
      - Upon crash recovery, ledger initialization will ensure
        that both state db and history db in sync with block storage
      
      Reused existing test logic, therefore the changeset
      is relatively large to ensure tests still pass.
      
      Change-Id: I79103aa39957f58d246de5b5295fb40a4b9c033b
      Signed-off-by: default avatardenyeart <enyeart@us.ibm.com>
      2c982629
  5. 24 Jan, 2017 1 commit
    • manish's avatar
      Detect phantom items during validation · 16372176
      manish authored
      https://jira.hyperledger.org/browse/FAB-1668
      
      
      
      Phantom reads problem:
      -----------------------------
      If a transaction executes a key range query (say key_1 - key_n) leveldb
      serves all the keys in the given range in sorted order of keys.
      Between simulation and validation of a transaction, some other transaction
      may insert one or more keys in this range. Now, this change cannot
      be detected by merely checking the versions of the keys present in
      the read-set of the transaction.
      (though, this check can detect updates and deletes).
      
      A serializable isolation level does not permit phantom reads.
      
      Situations where the phantom reads may not be acceptable:
      -----------------------------
       - A chaincode may take a decision based on aggregates of the results of
      the range query such as min/max/avg/sum etc. This would be affected
      if a new entry gets added to the range query results.
      
       - A chaincode may want to change all the marbles
      owned by a specific user to blue in a tran `t1`. The chaincode may do so
      by performing a range query to get all the marbles for the user and
      change their color to blue. Now, if a new white marble get added to
      the user's assets by an another transaction `t2`,
      `t1` should be marked as invalid.
      
      Solution in this change-set:
      -----------------------------
      For solving this, we can capture the details of the range query
      (the query and it's results) during the simulation time and
      re-execute the query during validation time and compare the results.
      If the results (keys and versions) are still the same,
      we can safely commit the transaction.
      
      This changes set introduces
       - Structures for capturing the range query details in rwset
       - Detection of phantom items (insertion/deletion)
         that affect the results of the range query during validation
       - Mark the transactions that are affected by the phantom items
         as invalid to ensure serializability in the presence of range queries
      
      Change-Id: I909841a0234c37795ad7a4ffcca8a9ebd9c9f994
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
      16372176
  6. 17 Jan, 2017 1 commit
    • manish's avatar
      SingleLevelDB for block index · 8cdd0f4d
      manish authored
      https://jira.hyperledger.org/browse/FAB-1664
      
      
      
      This changeset:
      - Renames package ledger/util/db to ledger/util/leveldbhelper
      - Implements a leveldb provider
        (that enables using same leveldb instance as a multiple logical dbs)
        in util package for being able to reuse across statedb, index,
        and later for historydb
      - Implements a provider as a single point of invocation
        for managing multiple block storage
      - Uses a single leveldb instance for block storage index
      - Makes the structures other than providers as private
        to their respective packages
      
      Change-Id: I5f0b3b9aa8ef3ac1ccdce4f3c6fa6d842b5318c1
      Signed-off-by: default avatarmanish <manish.sethi@gmail.com>
      8cdd0f4d
  7. 16 Jan, 2017 1 commit
  8. 15 Jan, 2017 1 commit
    • denyeart's avatar
      FAB-1505 and FAB-1337 Refactor CouchDB code · 9df7b0ea
      denyeart authored
      
      
      FAB-1505 refactors CouchDB code to be aligned with LevelDB structure.
      FAB-1337 applies all ledger tests written for LevelDB against CouchDB.
      
      In order to test the CouchDB refactor,
      had to implement FAB-1337 in same changeset to test.
      
      Like most refactors, this changeset touches a lot of files and code,
      since it is not feasible to do a partial refactor.
      
      Tests related to versioning and deleting have been commented out,
      these will be re-enabled in subsequent changeset when CouchDB
      has the support, in order to keep this changeset size more reasonable.
      
      Change-Id: I0d2d6cca89bd0252f6e84317457a9140b3a0d7a5
      Signed-off-by: default avatardenyeart <enyeart@us.ibm.com>
      9df7b0ea
  9. 08 Jan, 2017 1 commit
  10. 14 Dec, 2016 1 commit