|
#fabric-chaincode
#fabric-chaincode
how chaincode example 02 can be modified in hyperledger 1.4.4 help!!
how chaincode example 02 can be modified in hyperledger 1.4.4 help!!
|
By
music prime
· #8130
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
Thanks a lot Senthil :) I have been meaning to contribute to Hyperledger project, since I started learning Fabric around 2 years back. I guess this is a right time for me to start contributing to the
Thanks a lot Senthil :) I have been meaning to contribute to Hyperledger project, since I started learning Fabric around 2 years back. I guess this is a right time for me to start contributing to the
|
By
Prasanth Sundaravelu
· #8124
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
I see. Good to know. Anyway, keep up the good work. I am sure that Manish would be more interested in this work. When we were designing ledger for v1.0, Manish, in fact, proposed to build a query laye
I see. Good to know. Anyway, keep up the good work. I am sure that Manish would be more interested in this work. When we were designing ledger for v1.0, Manish, in fact, proposed to build a query laye
|
By
Senthil Nathan
· #8122
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
Sorry for not being clear. I have already formulated an encoding scheme that requires addition of 4 characters prefix and have implemented queries over that encoding format. But, If there is a good im
Sorry for not being clear. I have already formulated an encoding scheme that requires addition of 4 characters prefix and have implemented queries over that encoding format. But, If there is a good im
|
By
Prasanth Sundaravelu
· #8121
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
Hi Prasanth, I remember a similar request made in the past on enabling range queries on composite keys. Hence, we created this JIRA https://jira.hyperledger.org/browse/FAB-11281 but we didn't proceed
Hi Prasanth, I remember a similar request made in the past on enabling range queries on composite keys. Hence, we created this JIRA https://jira.hyperledger.org/browse/FAB-11281 but we didn't proceed
|
By
Senthil Nathan
· #8120
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
Hi Senthil, You are right to some extent. My first inspiration is from the composite keys. In fact, the first set of ideas involved just having composite key as index for each and every field in the s
Hi Senthil, You are right to some extent. My first inspiration is from the composite keys. In fact, the first set of ideas involved just having composite key as index for each and every field in the s
|
By
Prasanth Sundaravelu
· #8119
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
Hi Prasanth, Correct me if I am missing something. In our sample https://github.com/hyperledger/fabric-samples/blob/master/chaincode/marbles02_private/go/marbles_chaincode_private.go#L276, we create c
Hi Prasanth, Correct me if I am missing something. In our sample https://github.com/hyperledger/fabric-samples/blob/master/chaincode/marbles02_private/go/marbles_chaincode_private.go#L276, we create c
|
By
Senthil Nathan
· #8117
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
Without cache, the performance is very bad when fetching a large number of matching records as discussed in here: https://lists.hyperledger.org/g/fabric/topic/72797648?p=Created,,,20,2,0,0 Short summa
Without cache, the performance is very bad when fetching a large number of matching records as discussed in here: https://lists.hyperledger.org/g/fabric/topic/72797648?p=Created,,,20,2,0,0 Short summa
|
By
Prasanth Sundaravelu
· #8113
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
The problem is not the query, but the cache. You don't know whether to cache or not to cache until you have tried to do a PutState. There is already a cache in the peer itself... maybe drop the cache?
The problem is not the query, but the cache. You don't know whether to cache or not to cache until you have tried to do a PutState. There is already a cache in the peer itself... maybe drop the cache?
|
By
Yacov
· #8112
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
Oh yes, Write will only happen when "Create", "Update" and "Delete". In that case. But still, User will probably perform Query before calling Create or Update, so Query still won't know if it is a wri
Oh yes, Write will only happen when "Create", "Update" and "Delete". In that case. But still, User will probably perform Query before calling Create or Update, so Query still won't know if it is a wri
|
By
Prasanth Sundaravelu
· #8110
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
Well, if you want to do a write you would use a PutState. In theory you can also persist to the Blockchain, transactions that have an empty write set, which are basically queries, but I doubt it's wid
Well, if you want to do a write you would use a PutState. In theory you can also persist to the Blockchain, transactions that have an empty write set, which are basically queries, but I doubt it's wid
|
By
Yacov
· #8109
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
Hi Yacov, Multiple fields query: Eg: struct { ID string A string .. F string .. Z string } Generated Indeces: (Note: Field value is also present in the index) 1. StructName_A_foo_id1 2. StructName_B_b
Hi Yacov, Multiple fields query: Eg: struct { ID string A string .. F string .. Z string } Generated Indeces: (Note: Field value is also present in the index) 1. StructName_A_foo_id1 2. StructName_B_b
|
By
Prasanth Sundaravelu
· #8107
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
Hi Senthil, Question1: There is a problem with composite keys in performing full rich queries. Assume the same structure: sturct { ID string Name string } With composite keys, I can put it as: DocType
Hi Senthil, Question1: There is a problem with composite keys in performing full rich queries. Assume the same structure: sturct { ID string Name string } With composite keys, I can put it as: DocType
|
By
Prasanth Sundaravelu
· #8106
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
What if I have fields A, B, C, ... Z and I am asking about field F containing value "foo" ? Can you describe what indices are built and what is the range query? From: "Prasanth Sundaravelu" <prasanths
What if I have fields A, B, C, ... Z and I am asking about field F containing value "foo" ? Can you describe what indices are built and what is the range query? From: "Prasanth Sundaravelu" <prasanths
|
By
Yacov
· #8105
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
Could it be that the cache is only for reads and not for writes? Otherwise, even if it's simulated on peers of equal height, as Senthil said - without putting these reads into the read set and short-c
Could it be that the cache is only for reads and not for writes? Otherwise, even if it's simulated on peers of equal height, as Senthil said - without putting these reads into the read set and short-c
|
By
Yacov
· #8104
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
Hi Prasanth, Is it different from using a composite key https://github.com/hyperledger/fabric-samples/blob/master/chaincode/marbles02_private/go/marbles_chaincode_private.go#L276 ? One addition to abo
Hi Prasanth, Is it different from using a composite key https://github.com/hyperledger/fabric-samples/blob/master/chaincode/marbles02_private/go/marbles_chaincode_private.go#L276 ? One addition to abo
|
By
Senthil Nathan
· #8103
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
Hi Yacov, I will try to explain in short. Assume a structure: sturct { ID string Name string } 1. It will be converted to a series of index keys and one original key. 2. Index keys will hold informati
Hi Yacov, I will try to explain in short. Assume a structure: sturct { ID string Name string } 1. It will be converted to a series of index keys and one original key. 2. Index keys will hold informati
|
By
Prasanth Sundaravelu
· #8102
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
Can you explain in a few sentences the mechanics behind it? If I want to do a rich query that returns all keys that their value is "Yacov" - how do you do that without scanning the entire namespace ?
Can you explain in a few sentences the mechanics behind it? If I want to do a rich query that returns all keys that their value is "Yacov" - how do you do that without scanning the entire namespace ?
|
By
Yacov
· #8101
·
|
|
Rich Query on levelDB (~7x faster queries) - iState package
#fabric
#fabric-chaincode
Hi guys, I just released v1.0 of iState package. Check it out: https://github.com/prasanths96/iState iState is a state management package for Hyperledger fabric chaincode. It can be used to perform hi
Hi guys, I just released v1.0 of iState package. Check it out: https://github.com/prasanths96/iState iState is a state management package for Hyperledger fabric chaincode. It can be used to perform hi
|
By
Prasanth Sundaravelu
· #8100
·
|
|
#fabric-chaincode
#fabric-chaincode
Which version of fabric and fabric-samples are you using? example02 was renamed abstore over a year ago. I recommend you move to at least fabric-1.4.6 if not 2.0.1. -- Arnaud Le Hors - Senior Technica
Which version of fabric and fabric-samples are you using? example02 was renamed abstore over a year ago. I recommend you move to at least fabric-1.4.6 if not 2.0.1. -- Arnaud Le Hors - Senior Technica
|
By
Arnaud Le Hors
· #8085
·
|