Core Server
  1. Core Server
  2. SERVER-453

$iset - set fields only on insert when upserting

    Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Minor - P4 Minor - P4
    • Resolution: Duplicate
    • Affects Version/s: 1.1.3
    • Fix Version/s: None
    • Component/s: Querying
    • Labels:
      None
    • Backport:
      No
    • # Replies:
      8
    • Last comment by Customer:
      true

      Description

      It'd be nice if there was the ability to tell Mongo on an upsert, "set this field only if a new document is created".

      Example:

      db.users.update(

      { foo: 'bar'}

      , { $set:

      { baz: 'bap' }

      , $iset:

      { create_time: new Date() }

      }, true)

      You could also imagine an equivalent to only set fields when updating but not inserting, although when updating there are more things you might want to do than just set ($inc, $push, etc), this may need more thought as to best approach. Perhaps $updateonly which can then contain any number of possible modifications, e.g. { $updateonly: { $inc:

      { modifications: 1 }

      , $set:

      { modify_time: new Date() }

      }

        Issue Links

          Activity

          Hide
          Eliot Horowitz
          added a comment -

          i think the solution for upsert will also handle this

          Show
          Eliot Horowitz
          added a comment - i think the solution for upsert will also handle this
          Hide
          Matt Mastracci
          added a comment -

          I ran into this missing functionality today. An alternative syntax might be something like this (using $insert and $update to gate operations):

          db.users.update(

          { foo: 'bar'}

          , { $set:

          { baz: 'bap' }

          , $insert:

          { create_time: new Date() }

          , $update: { $inc:

          {"update_count", 1}

          } }, true)

          Show
          Matt Mastracci
          added a comment - I ran into this missing functionality today. An alternative syntax might be something like this (using $insert and $update to gate operations): db.users.update( { foo: 'bar'} , { $set: { baz: 'bap' } , $insert: { create_time: new Date() } , $update: { $inc: {"update_count", 1} } }, true)
          Hide
          Torsten Curdt
          added a comment -

          This seems to be a duplicate of http://jira.mongodb.org/browse/SERVER-340

          Show
          Torsten Curdt
          added a comment - This seems to be a duplicate of http://jira.mongodb.org/browse/SERVER-340
          Hide
          Keith Branton
          added a comment -

          +1 for Matt's suggestion of $insert and $update

          Eliot closed SERVER-2595 as a duplicate of this - so presumably this will work with findAndModify as well as update - that was what SERVER-2595 was about.

          Show
          Keith Branton
          added a comment - +1 for Matt's suggestion of $insert and $update Eliot closed SERVER-2595 as a duplicate of this - so presumably this will work with findAndModify as well as update - that was what SERVER-2595 was about.
          Hide
          Eliot Horowitz
          added a comment -

          @keith, yes, if this is part of the update spec it'll work fine with findAndModify

          Show
          Eliot Horowitz
          added a comment - @keith, yes, if this is part of the update spec it'll work fine with findAndModify
          Hide
          Tom Wardrop
          added a comment -

          I was after a similar thing the other week. I'm writing an object mapper that basically builds a queue of document operations, until a commit method is called. The operations are stored in a hash against the actual operator, e.g. {'$set' =>

          {name: 'Bill'}

          , '$inc' => {age: 2}}. If the document is new (i.e. if the object mapper doesn't know of an _id), then I obviously need some way to run these operations. The best I could come up with was issuing an insert command, for the sole purpose of generating an _id, and then doing an update so I could apply the queued operations.

          So the main use case I see for this is being able to apply modifiers (e.g. $set, $inc, etc) during an insert operation. The above suggestion would accommodate this (not ideal, but a solution none the less).

          Show
          Tom Wardrop
          added a comment - I was after a similar thing the other week. I'm writing an object mapper that basically builds a queue of document operations, until a commit method is called. The operations are stored in a hash against the actual operator, e.g. {'$set' => {name: 'Bill'} , '$inc' => {age: 2}}. If the document is new (i.e. if the object mapper doesn't know of an _id), then I obviously need some way to run these operations. The best I could come up with was issuing an insert command, for the sole purpose of generating an _id, and then doing an update so I could apply the queued operations. So the main use case I see for this is being able to apply modifiers (e.g. $set, $inc, etc) during an insert operation. The above suggestion would accommodate this (not ideal, but a solution none the less).
          Hide
          Eliot Horowitz
          added a comment -
          Show
          Eliot Horowitz
          added a comment - SERVER-340
          Hide
          Daniel Doubrovkine
          added a comment -

          In my case I am doing a $set for the same value, I presume I am paying the price for that. It would be useful to know how expensive the operation is. Of course, $insert (from above) is what I mean to do, +1 for that.

          Show
          Daniel Doubrovkine
          added a comment - In my case I am doing a $set for the same value, I presume I am paying the price for that. It would be useful to know how expensive the operation is. Of course, $insert (from above) is what I mean to do, +1 for that.

            People

            • Votes:
              15 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since reply:
                22 weeks, 3 days ago
                Date of 1st Reply: