Details
-
Bug
-
Resolution: Fixed
-
Major
-
6.6.2
-
Untriaged
-
Impediment
-
1
-
Unknown
Description
The problem is there in 4.0.0 . This problem already fixed in 7.0 as part of different feature.
SQL statement must mutate row once only (Halloween problem).
When IndexScan done index only gives non-duplicate document keys, In case of Array Index key query does DistinctScan on document keys.
When user provides USE KEYS, we do KeyScan which must dedup keys to avoid this.
default pipelinebatch is 16 so for repro purpose used 17 keys with 1 duplicate
INSERT INTO default VALUES("k01", {"a":1}), VALUES("k02", {"a":1}), VALUES("k03", {"a":1}), VALUES("k04", {"a":1}), |
VALUES("k05", {"a":1}), VALUES("k06", {"a":1}), VALUES("k07", {"a":1}), VALUES("k08", {"a":1}), |
VALUES("k09", {"a":1}), VALUES("k10", {"a":1}), VALUES("k11", {"a":1}), VALUES("k12", {"a":1}), |
VALUES("k13", {"a":1}), VALUES("k14", {"a":1}), VALUES("k15", {"a":1}), VALUES("k16", {"a":1}); |
UPDATE default AS d USE KEYS ["k01", "k02", "k03", "k04", |
"k05", "k06", "k07", "k08", |
"k09", "k10", "k11", "k12", |
"k13", "k14", "k15", "k16", |
"k16"] |
SET d.a = 1; |
|
|
"errors": [ |
{
|
"code": 12009, |
"msg": "DML Error, possible causes include CAS mismatch or concurrent modificationFailed to perform update - cause: MCResponse status=KEY_EEXISTS, opcode=SET, opaque=0, msg: " |
}
|
],
|
Another Use case
USE KEYS (SELECT RAW META(d).id FROM default AS d UNNEST d.arr AS u WHERE ...)
subquery results can have duplicates due to UNNEST.
Workaround is ARRAY_DISTINCT() around USE KEYS. Or DISTINCT in subquery projection.