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. 28 Nov, 2018 1 commit
  11. 19 Nov, 2018 1 commit
  13. 16 Nov, 2018 1 commit
  15. 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
  17. 05 Sep, 2018 2 commits
  19. 09 Aug, 2018 1 commit
  21. 16 Jul, 2018 7 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
    • Jason Yellick's avatar
      FAB-10292 Update protobuf to v1.1.0 · 03104e71
      Jason Yellick authored 
      

Protobuf was slated to be updated already, but there is a long list of
incompatibilities with the current source tree.

Thi CR updates protobuf to v1.1.0, and addresses those
incompatibilities.  Most of the changes are quite rote and fall into one
of three buckets.

1. Code which uses non-keyed field initialization.  (ie, initializing a
struct like MyStruct{value1, value2, value3}).  The newer generated
protos produces structs which have additional non-field members.
Structs should always be initialized with named fields, regardless of
whether they are protos or not.

2. Code which assumes that reflect.DeepEqual between two protos with the
same fields will return true.  This has never been the case, especially
when considering protos with slice or map fields, but with proto v1.1.0
with the addition of caching and other members to the proto structs, it
is even less true.  The correct call is proto.Equal.

3. Code which assumes that proto fails on bad inputs -- the proto spec
has always stated that failure _may_ occur, not that it must.  Certain
code would attempt to determine proto message type based on failure to
unmarshal, which was unsafe in v1.0.0, but is even more likely to cause
problems in v1.1.0.

4. On average, half of gossip identity digests aren't valid UTF8 strings,
   and proto v1.1.0 now enforces UTF8 validity checks for string fields.
   Therefore, the field was converted to bytes.

Change-Id: I74cc037903137705dbe3f4e27e34d1307596db3b
Signed-off-by: default avatarJason Yellick <jyellick@us.ibm.com>
Signed-off-by: default avataryacovm <yacovm@il.ibm.com>
      03104e71
  23. 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
  25. 22 May, 2018 3 commits
  27. 14 May, 2018 2 commits
  29. 11 May, 2018 1 commit
  31. 10 May, 2018 2 commits
  33. 25 Apr, 2018 2 commits
  35. 23 Apr, 2018 1 commit
  37. 21 Feb, 2018 1 commit
    • Luis Sanchez's avatar
      [FAB-8103] final HasMore should return false · a6885b58
      Luis Sanchez authored 
      

final GET_STATE_BY_RANGE response now indicates that
there are no more results when the total number of
responses are a multiple of maxResultLimit (the maximum
number of responses that can be returned in a single
GET_STATE_BY_RANGE response).

Change-Id: Ifd482f6f0951ac69698a5cd9f2c610ef84654bf7
Signed-off-by: default avatarLuis Sanchez <sanchezl@us.ibm.com>
      a6885b58