[SERVER-390] upsert with x.y query misinterpreted by server Created: 27/Oct/09 Updated: 12/Jul/16 Resolved: 16/Jan/10 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Write Ops |
| Affects Version/s: | 1.0.0 |
| Fix Version/s: | 1.3.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jason Sachs | Assignee: | Eliot Horowitz (Inactive) |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Looks like one of the upsert syntaxes is misinterpreted on the server > db.testcoll.drop(); {"nIndexesWas" : 1 , "msg" : "all indexes deleted for collection" , "ns" : "mfs.testcoll" , "ok" : 1}> db.testcoll.update({foo: {bar: 123}}, {"$inc": {"baz": 1}}, {upsert: true}) {"_id" : ObjectId( "4ae725fd4666000000000f21") , "foo" : {"bar" : 123} , "baz" : 1} and containing no other fields. It doesn't exist so we > db.testcoll.update( {"foo.bar": 123}, {"$inc": {"baz": 1}}, {upsert: true}) {"_id" : ObjectId( "4ae725fd4666000000000f21") , "foo" : {"bar" : 123} , "baz" : 2} > db.testcoll.drop() {"nIndexesWas" : 1 , "msg" : "all indexes deleted for collection" , "ns" : "mfs.testcoll" , "ok" : 1}> db.testcoll.update( {"foo.bar": 123}, {"$inc": {"baz": 1}}, {upsert: true}) // Again we upsert an object with a foo field containing a bar field and creates a new |
| Comments |
| Comment by auto [ 16/Jan/10 ] |
|
Author: {'name': 'Eliot Horowitz', 'email': 'eliot@10gen.com'}Message: fix upset with x.y query and $mod |
| Comment by Jon Stephens [ 13/Jan/10 ] |
|
I get the same thing from the Perl driver on 1.2.1. See PERL-48. Didn't see this bug until now. |
| Comment by Eliot Horowitz (Inactive) [ 16/Dec/09 ] |
|
split out case for $ queries |
| Comment by Ian White [ 03/Dec/09 ] |
|
Here's another, somewhat related, problem with upserts – feel free to split but you might be able to kill these two birds with one stone: > db.test.drop(); }, { $push: { fruits: 'apple' }}, { upsert: true } ); (I'm using the $ne conditional as a workaround for the lack of a $pushUnique / $pushAllUnique) Anyway, the problem is that the first parameter is doing double duty as both criteria and the object to insert, so mongo thinks I mean to insert the literal subobject { $ne: 'apple' }, and then run a $push on it, which isn't allowed. Jason is encountering a similar problem: the dot-notation he's using for criteria is not suitable for the inserted object. I'm starting to think it might be best if upsert was different from update and was something like upsert(criteria, insert, update) This would fix Jason's problem, because he'd do: db.testcol.upsert( { 'foo.bar': 123 }, { foo: { bar: 123 }, baz: 1 }, { $inc: { baz: 1 }} ); And it would fix my problem, because I'd do (at least until we get $pushUnique): db.test.upsert( { name: 'ian', fruits: { $ne: 'apple' }}, { name: 'ian', fruits: ['apple'] }, { $push: { fruits: 'apple' }} ) And it would resolve #453 as well. |