GetQueryResult interface have this comment:
The query is NOT re-executed during validation phase, phantom
not detected. That is, other committed transactions may have
updated, or removed keys that impact the result set, and this
be detected at validation/commit time. Applications susceptible
should therefore not use GetQueryResult as part of transactions
ledger, and should limit use to read-only chaincode operations."
If we use previous example, this means that if GetQueryResult is used to take all marbles owned
by Bob, then this result will not be validated during commit. So
if someone has changed or updated some of the Bobs marbles, then
we have possible double spending, split brain, data divergence
... call it as you wish. If GetState is used instead, then
result will be validated during commit time.
This is my understanding, this is what
official documentation and code comments are explaining, this is
what I have observed in version 1.0 during tests.
If this is changed in 1.1, please, update the
documentation and comments, because it will be much more easy
for us all to work with rich queries that validate the result
On 21.04.2018 20:25, jeronimo irazabal
Following the discussion
I think the statement that using Couchdb will make MVCC
fail is not correct. Because that validation is made in
the very same way in despite of the underlying state
database being used (leveldb or couchdb). Whenever a
chaincode makes use of the KeyValue API, the readwrite-set
is prepared in-memory at the endorsing peer level by the
transaction simulator. For rich-queries, the digest of the
result is included in the read part (that last solution
was not present on earlier versions of the Fabric).
When we added SQL capabilities at chaincode level, we had to
create a new transaction simulator, use a different
read-write set and a new validation procedure because we
didn't employed MVCC. But the validation made when using
Leveldb or Couchdb is the same.
However, I think Ivan had another motivation, that's to reduce
the number of transactions that get invalidated due to MVCC,
and his approach is to use different keys as much as possible.
While this a required workaround due to MVCC, I'm not able to
see why if using the same keys using Couchdb would make any
difference with using leveldb instead.