plan/spec: the operator corpus goes green
102/102. PLAN's M3 row now names both corpora as the gate, because neither the pinned crud suite nor e2e3/e2e4 can see this work: the eight operators are barely in the pinned corpus and `$push`'s modifiers are not in it at all. §6 records what the corpus found that was nobody's operator -- an upsert never reporting the `_id` it generated -- and the three things left open on purpose: `$bit`, a multi-field `$sort` key inside `$push`, and the 64-path bound on the conflict check. Full matrix at this commit: 247/247 unit tests in ReleaseFast and ReleaseSafe, 83/83 fuzz, operators 102/0, positional 51/0, aggregation 70/0, pinned crud 218/73/196 unmoved, e2e and crash-fuzz green.
This commit was merged in pull request #8.
This commit is contained in:
@@ -58,21 +58,27 @@ as a bare number would not have said so.
|
||||
|
||||
## Where it stands
|
||||
|
||||
Recorded against mongod 8.3.7, run against the server before any of it was
|
||||
implemented:
|
||||
Recorded against mongod 8.3.7. Green:
|
||||
|
||||
```
|
||||
array-ops.json 2 pass 24 fail 0 skip
|
||||
current-date.json 3 pass 8 fail 0 skip
|
||||
modifiers.json 7 pass 7 fail 0 skip
|
||||
numeric.json 0 pass 21 fail 0 skip
|
||||
push-modifiers.json 6 pass 15 fail 0 skip
|
||||
set-on-insert.json 0 pass 9 fail 0 skip
|
||||
array-ops.json 26 pass 0 fail 0 skip
|
||||
current-date.json 11 pass 0 fail 0 skip
|
||||
modifiers.json 14 pass 0 fail 0 skip
|
||||
numeric.json 21 pass 0 fail 0 skip
|
||||
push-modifiers.json 21 pass 0 fail 0 skip
|
||||
set-on-insert.json 9 pass 0 fail 0 skip
|
||||
```
|
||||
|
||||
Red by construction. The 18 that pass are the shapes this server already
|
||||
answers the way mongod does — mostly refusals that happen to agree, plus the
|
||||
`$push` cases with no modifier on them.
|
||||
It was recorded red — 18 pass / 84 fail against a server with none of these
|
||||
operators — and driven green by seven commits. The 18 that passed then were
|
||||
the shapes this server already answered mongod's way, mostly refusals that
|
||||
happened to agree.
|
||||
|
||||
It also found a bug nothing else here had: an upsert never reported the `_id`
|
||||
it generated, so `updateOne(..., {upsert: true}).upsertedId` was null and
|
||||
`findOneAndUpdate` with `returnDocument: after` returned a document with no
|
||||
`_id`. This is the first corpus here that upserts into an empty collection and
|
||||
then looks at what came back.
|
||||
|
||||
## What recording it settled
|
||||
|
||||
|
||||
Reference in New Issue
Block a user