[SERVER-33226] Get rid of the `getPrevError` command Created: 09/Feb/18  Updated: 29/Oct/23  Resolved: 10/Jan/19

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 4.1.7

Type: Task Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: Kim Tao
Resolution: Fixed Votes: 0
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
is depended on by DRIVERS-599 Fix test failures caused by removal o... Closed
Documented
is documented by DOCS-12215 resetError deprecation status Closed
Related
related to DOCS-11407 deprecate and remove getPrevError com... Closed
related to DOCS-11408 Document the getPrevCommand as deprec... Closed
related to PYTHON-1719 Fix test failures caused by removal o... Closed
Backwards Compatibility: Fully Compatible
Backport Requested:
v4.0
Sprint: Sharding 2018-12-17, Sharding 2018-12-31, Sharding 2019-01-14
Participants:

 Description   

The getPrevError command is a command which allowed callers to do several writes with getLastError and offers the ability to read the last error which occurred and how many commands back it was. getLastError refers to result of the last write where getPreviousError refers to last error that happened.

Example:

db.foo.insert({_id:1})
WriteResult({ "nInserted" : 1 })
db.foo.insert({_id:1})
WriteResult({
	"nInserted" : 0,
	"writeError" : {
		"code" : 11000,
		"errmsg" : "insertDocument :: caused by :: 11000 E11000 duplicate key error index: test.foo.$_id_  dup key: { : 1.0 }"
	}
})
db.foo.insert({_id:2})
WriteResult({ "nInserted" : 1 })
db.foo.insert({_id:3})
WriteResult({ "nInserted" : 1 })
db.foo.insert({_id:4})
WriteResult({ "nInserted" : 1 })
db.getLastError()
null   // last write did not have an error
db.getPrevError()
{  
	"err" : "insertDocument :: caused by :: 11000 E11000 duplicate key error index: test.foo.$_id_  dup key: { : 1.0 }",
	"code" : 11000,
	"n" : 1,
	"nPrev" : 4,   // last error was four commands ago
	"ok" : 1
}

This functionality is not used by any MongoDB driver and with the availability of write commands and OP_MSG is not necessary as well, so we should remove it.



 Comments   
Comment by Githook User [ 10/Jan/19 ]

Author:

{'username': 'Kimchelly', 'email': 'kimberly.tao@mongodb.com', 'name': 'Kim Tao'}

Message: SERVER-33226: remove getPrevError() command
Branch: master
https://github.com/mongodb/mongo/commit/47262867106c18aec3bc385dc13a5b0e90f33e7f

Comment by Gregory McKeon (Inactive) [ 02/Mar/18 ]

Linked docs ticket.

Comment by Asya Kamsky [ 02/Mar/18 ]

Yes, confirming. Should we open a DOCS ticket to add a deprecation note in current (3.6) docs for command (even though it's internal command still that would cover all bases).

Comment by Gregory McKeon (Inactive) [ 02/Mar/18 ]

Based on Slack conversations with Asya and Dan, this is fine.

Comment by Kaloian Manassiev [ 02/Mar/18 ]

I had an email exchange with the drivers team and they did not have any objections to deleting this command, so I think we can just get rid of it. It also doesn't work in sharding.

asya, please confirm that it is alright to just get rid of it in 4.0?

Comment by Gregory McKeon (Inactive) [ 16/Feb/18 ]

asya do we need to deprecate? This is still documented as supported in 3.6. The shell helper is deprecated, but the command is not: https://docs.mongodb.com/manual/reference/command/getPrevError/

Comment by Charlie Swanson [ 16/Feb/18 ]

The query team is happy to see this command go away, but don't want to spend the time deleting it. Moving to Sharding Team.

Comment by Asya Kamsky [ 09/Feb/18 ]

Also noting that a number of tests use this command.

Comment by Asya Kamsky [ 09/Feb/18 ]

I don't think this should be sharding team backlog (since it's not even supported with sharding) but query (or platform?) david.storch thoughts?

Comment by Asya Kamsky [ 09/Feb/18 ]

Note that it relies on reseterror command to be run to clear error state it reads so maybe that should be candidate for removal as well.

Generated at Thu Feb 08 04:32:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.