You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: Use JSON for stdio, similiar to the HTTP Transport and use EJSON.deserialize when necessary
We can't leverage using EJSON as the underlying transport because it
diverges from the HTTP Transport, and because not all EJSON is
equivalent to it's underlying JSON. For example, take this sample into
consideration:
```js
$> JSON.stringify({ long: 23098479807234 })
<= {"long":23098479807234}
$> EJSON.stringify({ long: 23098479807234 }) // relaxed = true
<= {"long":23098479807234}
$> EJSON.stringify({ long: 23098479807234 }, { relaxed: false })
<= "long":{"$numberLong":"23098479807234"}}
```
This behaviour forbids us on using `{relaxed: false}` always, as it breaks
the shape of the underlying JSON. Moreover, if we use dates, it gets
worse, as we lose type info in the protocol when
serialising/deserializing.
The approach here is to use a custom `zod` type that leverages on
EJSON.deserialize, a function that reads a plain EJSON object and
transforms it to the underlying types (for example, $date to js.Date).
This is important because the Node.js driver does not work with EJSON, it
works with actual JS objects (like Date), so by using this approach
documents and queries using non-primitive types like BinData or Date
work as expected.
0 commit comments