Skip to content
GitLab
  1. 02 Mar, 2019 1 commit
  3. 05 Dec, 2018 1 commit
    • Senthil Nathan N's avatar
      pvtData APIs are not allowed in chaincode Init() · 3e7b2efd
      Senthil Nathan N authored 
      

private data APIs are not allowed in Init() since the
private data collection configuration is not yet committed
on the channel.

This CR provide a better error message indicating that
pvtdata APIs are  not allowed in chaincode Init().

FAB-13050 #done

Change-Id: I6e6a8abdf1f35f56307be90d8b6b2830c8f35755
Signed-off-by: default avatarsenthil <cendhu@gmail.com>
      3e7b2efd
  5. 02 Dec, 2018 1 commit
  7. 01 Dec, 2018 1 commit
  9. 30 Nov, 2018 1 commit
  11. 28 Nov, 2018 1 commit
  13. 19 Nov, 2018 1 commit
  15. 16 Nov, 2018 1 commit
  17. 13 Nov, 2018 1 commit
  19. 29 Oct, 2018 1 commit
  21. 07 Sep, 2018 2 commits
    • senthil's avatar
      FAB-11455 peer side changes to support pagination · 0ee45ac4
      senthil authored 
      

We need to make necessary changes in the core/chaincode/handler.go for
pagination of results. Currently, the handler.go in the peer calls the ledger
to execute queries (range query, rich query) on behalf of the chaincode.
On an execution of a query, the ledger returns an iterator. Using the
iterator, peer constructs the query response with records and send the
response to chaincode.

This CR makes the following changes to support pagination of results.

When a pagination of results is enabled for a query (i.e., when the query
metadata is passed with either pageSize or a bookmark or both for range/rich
queries), the peer would call the new pagination enabled range/rich query
APIs at ledger which would return a response metadata in addition to an
iterator. The response metadata would contain the next bookmark and the
number of records fetched for the query. Peer retrieves all fetched records
from ledger, constructs a query response including both records and
response metadata. The chaincode can pass on the bookmark in the response
metadata to the application/sdk.

Change-Id: Id770dd184369d1f7eaa30f046e1923c8fde564a5
Signed-off-by: default avatarsenthil <cendhu@gmail.com>
Signed-off-by: default avatarChris Elder <chris.elder@us.ibm.com>
      0ee45ac4
    • Matthew Sykes's avatar
      [FAB-11911] address review comments for statebased · b4c223a2
      Matthew Sykes authored 
      

Address a handful of comments related to the CR chain merged for state
based endorsement in the chaincode package.

Change-Id: I5b87ff172dfdc79c8070c89feeea6f5535ba39bc
Signed-off-by: default avatarMatthew Sykes <sykesmat@us.ibm.com>
      b4c223a2
  23. 05 Sep, 2018 3 commits
  25. 09 Aug, 2018 2 commits
  27. 16 Jul, 2018 6 commits
    • Jason Yellick's avatar
      FAB-11037 Remove InvocationSpec from chaincode pkg · 1fe243f8
      Jason Yellick authored 
      

This CR finally completes removing the legacy data "ChaincodeSpec"
structures from the non-shim related pieces of the chaincode package.
To maintain compatibility with the existing chaincode images, the
ChaincodeSpec still exists in the handler path, and to maintain
compatibility with the legacy lifecycle, a single deployment spec
acceing execute method is available.  Both of these should be removed in
time.

Change-Id: I5659695a55e0947a1ccec23721192a4c88177b38
Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      1fe243f8
    • Jason Yellick's avatar
      FAB-11036 Remove the transaction parms from cccid · 354c9242
      Jason Yellick authored 
      

The chaincode context structure help the channel id, the chaincode name,
chaincode version, and other things unrelated to identifying a chaincode
like the proposal bytes.  These other fields are also stored in the
transaction parms, so, they are not needed and are confusing when in the
chaincode context.  This CR removes them.

Change-Id: I892bd24cc621800cd1b089d90d0a603e112ae84c
Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      354c9242
    • Jason Yellick's avatar
      FAB-11034 Replace context with explicit params · 4645c3ac
      Jason Yellick authored 
      

Presently, there is a "context" which is passed into the chaincode
package.  Rather than actually be used for its intended purpose (of
waiting for cancelation), the context is never actually checked.
Instead, it simply carries the transaction simulators around in an
opaque fashion.

It's much better to make these transaction simulators to be passed in
explicitly.  Additionally, some other facets like TxID and the assorted
proposals really fit much more naturally with the simulators and not
with the chaincode context.  So, this CR brings them in as well.

Change-Id: I7e0c43af22f1e96b8d302e5cf877e7beec36598b
Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      4645c3ac
    • Jason Yellick's avatar
      FAB-11031 Remove 'Syscc' from CCContext · d72773ea
      Jason Yellick authored 
      

The syscc attribute is only used as part of deciding whether or not to
print a log message.  And, it is unnecessary in this case, so, removing
it.

Change-Id: I17ff4f654984240deddb726cc5902f83232993c3
Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      d72773ea
    • Jason Yellick's avatar
      FAB-11026 Remove lifecycle shim and use LSCC inst · 620dffee
      Jason Yellick authored 
      

There was a shim created by the chaincode package to abstract away
lifecycle operations.  Over time, this shim has done less and less as
the LSCC implementation has exposed more function directly rather than
as chaincode calls.  Now, the shim is only translating names.  This CR
simply aligns the names and removes the shim.

Change-Id: Ide10dbe5b872752458dca87b0a520b946a644afd
Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      620dffee
    • Jason Yellick's avatar
      FAB-10998 GetChaincodeData to use LSCC directly · d861bbfe
      Jason Yellick authored 
      

Now that LSCC can be queried directly for chaincode definitions instead
of having to go the roundabout way of invoking chaincode, the assorted
internal users of 'getccdata' can be converted to use the new interface.

Change-Id: Ic435742817643d2dc08d83afe2f66980c649b56a
Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      d861bbfe
  29. 10 Jul, 2018 1 commit
    • Jason Yellick's avatar
      FAB-10975 Split Execute into Execute/ExecuteInit · 59182528
      Jason Yellick authored 
      

Presently, the Execute function can either take a
'ChaincodeInvocationSpec' or a 'ChaincodeDeploymentSpec', and the path
switches in a few different places depending on which it is.  This makes
the code complicated and difficult to understand, and in the interest of
removing the chaincode deployment spec entirely, this code path should
be isolated.

Change-Id: I1f54684dba5877b5c629a59d344803f6423cc3da
Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
      59182528
  31. 02 Jul, 2018 1 commit
    • Matthew Sykes's avatar
      [FAB-9132] Fix data race in core/chaincode/shim · 635bce55
      Matthew Sykes authored 
      

Fix data race in the shim

A data race existed between reading and setting the error value returned
from stream.Recv(). Modify the shim to avoid the race and add a bit more
alignment between the peer and shim stream processing functions.

Fix data races in MockCCComm

- Quit was causing a race between channel send and close. Resolved by
  wiring a channel to Run and closing send and receive after the done
  channel had closed.
- The keep alive go routine was racing on the keepAlive message during
  send. Wired the done channel into the keep-alive go routine.
- Some tests are setting responses while go routines are running. Work
  around this bad behavior with a lock to avoid restructuring tests.

Change-Id: I49bab82336bbbeb941b7db2d8bd279f254b4ec9f
Signed-off-by: default avatarMatthew Sykes <sykesmat@us.ibm.com>
      635bce55
  33. 22 May, 2018 4 commits
  35. 14 May, 2018 2 commits
  37. 11 May, 2018 1 commit
  39. 10 May, 2018 8 commits