1. 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
  2. 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
  3. 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
  4. 16 Jan, 2017 1 commit
  5. 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
  6. 08 Jan, 2017 1 commit
  7. 14 Dec, 2016 1 commit