feat: add explain support for cursor commands #2622
Conversation
|
|
||
| const testCases = [ | ||
| { readConcern: { level: 'local' } }, | ||
| { writeConcern: { j: true } }, | ||
| { readConcern: { level: 'local' }, writeConcern: { j: true } } | ||
| ]; |
There was a problem hiding this comment.
This test was passing because the write concern was inherited from the client, making it look like using read concern with explain would fail on the server, when really it was the inherited write concern causing the server to return an error.
There was a problem hiding this comment.
I'm a little confused about this, why do we want to stop throwing an error if you use explain + readConcern? To me it looks like this test would still be passing due to the an error generated by the driver if not for the change here.
There was a problem hiding this comment.
The server doesn't actually throw an error when you just use explain & readConcern, so it is unnecessary to throw from the driver in this case. If you remove the driver error, the server would return an error for this test case because the write concern is inherited from the client, meaning explain is being used with writeConcern, not because there is any issue with explain & readConcern. Does that help?
There was a problem hiding this comment.
To clarify what I'm confused about: this test was explicitly expecting the failure to happen client-side rather than server-side, and from what I can see it was only the change to AggregateOperation that caused this client-side error to stop happening, so I'm not sure I see how the server throwing an error because of the inherited write concern would effect this test. I'd expect a server-side error to cause the test to fail with the Expected aggregation to fail on client instead of server for option message.
I think we were using this error as a hint to the user that read concern isn't supported by the explain operation, rather than merely as a way of avoiding a server-side error, and that we're no longer providing that guidance to the user with this change. I can see an argument in favor of this - they just want to get their explain results, and we should just ignore the read concern the way the server does; just wanted to fully understand the reason for the change.
There was a problem hiding this comment.
Ah, thanks for the clarification, I was misunderstanding.
I agree with what you're saying at the end. I think it makes sense to not error, since the server also ignores the read concern and since it's not really an error condition, in my opinion, in that nothing has gone wrong/is in an invalid state. I could imagine including a warning or possibly something in the documentation (for all of the explainable operations, not just aggregate), if we feel like the user needs this guidance. What do you think?
There was a problem hiding this comment.
I agree it seems unnecessary to warn about a read concern on explain operations. Is there any additional context you could provide about this @mbroadst ?
There was a problem hiding this comment.
Unfortunately, I can't recall the rationale for that check, I think it was added before my time and we don't have any specifications covering this. We have a similar situation here where we throw a client-side error if a non-local readConcern is provided for servers which don't support it - the server would otherwise ignore the value, it's not clear why we throw an error client-side.
I'm pro this change if it doesn't break any of our tests
HanaPearlman
force-pushed
the
NODE-2853/master/explain-cursor
branch
from
97294d9
to
5c4cfd9
Compare
This PR implements explain functionality for
findOne,find, andaggregate.These operations can be explained via the
explainoption introduced in #2599 or with theexplainmethod on cursors, which now takes an optionalverbosityparameter (defaults totruefor backwards compatibility).