[COMPASS-5528] Compass replaces whole array if you update one field in an array of objects Created: 21/Feb/22  Updated: 10/Jan/24  Resolved: 13/Jul/22

Status: Closed
Project: Compass
Component/s: Compass, CRUD
Affects Version/s: None
Fix Version/s: 1.32.4

Type: Bug Priority: Major - P3
Reporter: Andrzej Taramina Assignee: Anna Henningsen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MongoDB v5.0.6
Compass v1.30.1


Issue Links:
Problem/Incident
Related
is related to COMPASS-6011 Unable to add data to documents in Co... Closed
is related to COMPASS-4345 Compass does a replace instead of an ... Closed
is related to COMPASS-5753 JSON editor is the only way to change... Open
Story Points: 8
Documentation Changes: Not Needed
Sprint: Iteration Eel, Iteration Fish

 Description   

 

The Compass documentation here: https://docs.mongodb.com/compass/master/documents/modify/

says "When you edit a document in List or Table view, Compass performs a findOneAndUpdate operation and updates only those fields that you have changed."

When it comes to updating arrays of subdocuments this is not true and is very misleading.

If you update a single field in a subdocument that is in an array of subdocs, then Compass replaces the whole array.

This makes using/testing Change Streams with Compass problematic, since the Change Event will contain the whole array of subdocs, rather than just the fields that the user actually changed.

It would be very useful if Compass used $set specifications in the update operation for individual fields. 

Since Compass does know the name of the array field and the index of the entry in that array, generating $set's that look like:

$set: {
   "mySubdocArray.7.myChangedField":  newValue
}

should be quite doable.



 Comments   
Comment by Githook User [ 30/Aug/22 ]

Author:

{'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}

Message: feat(hadron-document)!: handle nested fields and dots & dollars well COMPASS-5805 (#3239)

  • Instead of fully replacing top-level properties only when editing
    documents, set only the individual nested values that have been
    edited.
  • This does not apply to array item removals, since there is no
    way to perform this (at least in MongoDB 4.0, but doing so
    on newer versions is also not straightforward).
  • Use `$getField` and `$setField` to modify fields whose names
    contain dots or start with a dollar sign.
    This is kind of a breaking change in that, previously, we
    would have queried for the field names containing dots,
    the server would have interpreted the field name as referring
    to nested documents, almost never found a document matching that
    (unless the doc happened to have a shape like
    `
    Unknown macro: { x}

    ` with matching values), and we then
    prompted the user to force-update due to the assumption that
    no document having been found means that it has been updated
    in the background.
    After this change, we just inform users that doing this
    properly requires MongoDB 5.0 or above. Users can still perform
    edits through the JSON view, at least for now (potentially only
    until COMPASS-5753 is done).

  • Split the query/update document generation parts into two steps,
    and move these out of the `Document` class to `ObjectGenerator`
    (which is already a collection of static methods for recursively
    traversing a document/element tree).
  • In the first step, gather all the elements that were updated,
    their original paths and values and their new paths and values.
  • In the second step, build either a query out of those original
    paths and values, or build the update document out of the new
    paths and values.
  • Drive-by bugfixes:
  • When renaming elements, we previously did not check that the
    new name was not already added in the background. We check
    this as well now.
  • Handle the case in which elements are renamed circularly,
    e.g. key2 → key3, key1 → key2 (or similar add/remove situations).
  • Use string arrays instead of objects that are only being used
    to extract their keys in the hadron-document API for hopefully
    a bit more API clarity.
  • Clarify in the docs that dots inside field names refer to
    nested documents. This is the way that sharding behaves,
    which is why we use them in the first place, and is not
    a practical API to break. (And if it does, there is an
    upcoming server sharding project will hopefully already have
    made inclusion of the shard keys unnecessary.)

This also addresses COMPASS-5528 (which is about adjusting the
update document sent to the server, whereas COMPASS-5805 is about
adjusting the query document).
Branch: compass-settings
https://github.com/mongodb-js/compass/commit/c865b66bd7c443da8f9d6ab9815aabf98175d8b5

Comment by Githook User [ 18/Jul/22 ]

Author:

{'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}

Message: feat(hadron-document)!: handle nested fields and dots & dollars well COMPASS-5805 (#3239)

  • Instead of fully replacing top-level properties only when editing
    documents, set only the individual nested values that have been
    edited.
  • This does not apply to array item removals, since there is no
    way to perform this (at least in MongoDB 4.0, but doing so
    on newer versions is also not straightforward).
  • Use `$getField` and `$setField` to modify fields whose names
    contain dots or start with a dollar sign.
    This is kind of a breaking change in that, previously, we
    would have queried for the field names containing dots,
    the server would have interpreted the field name as referring
    to nested documents, almost never found a document matching that
    (unless the doc happened to have a shape like
    `
    Unknown macro: { x}

    ` with matching values), and we then
    prompted the user to force-update due to the assumption that
    no document having been found means that it has been updated
    in the background.
    After this change, we just inform users that doing this
    properly requires MongoDB 5.0 or above. Users can still perform
    edits through the JSON view, at least for now (potentially only
    until COMPASS-5753 is done).

  • Split the query/update document generation parts into two steps,
    and move these out of the `Document` class to `ObjectGenerator`
    (which is already a collection of static methods for recursively
    traversing a document/element tree).
  • In the first step, gather all the elements that were updated,
    their original paths and values and their new paths and values.
  • In the second step, build either a query out of those original
    paths and values, or build the update document out of the new
    paths and values.
  • Drive-by bugfixes:
  • When renaming elements, we previously did not check that the
    new name was not already added in the background. We check
    this as well now.
  • Handle the case in which elements are renamed circularly,
    e.g. key2 → key3, key1 → key2 (or similar add/remove situations).
  • Use string arrays instead of objects that are only being used
    to extract their keys in the hadron-document API for hopefully
    a bit more API clarity.
  • Clarify in the docs that dots inside field names refer to
    nested documents. This is the way that sharding behaves,
    which is why we use them in the first place, and is not
    a practical API to break. (And if it does, there is an
    upcoming server sharding project will hopefully already have
    made inclusion of the shard keys unnecessary.)

This also addresses COMPASS-5528 (which is about adjusting the
update document sent to the server, whereas COMPASS-5805 is about
adjusting the query document).
Branch: 1.32-releases
https://github.com/mongodb-js/compass/commit/c865b66bd7c443da8f9d6ab9815aabf98175d8b5

Comment by Githook User [ 14/Jul/22 ]

Author:

{'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}

Message: feat(hadron-document)!: handle nested fields and dots & dollars well COMPASS-5805 (#3239)

  • Instead of fully replacing top-level properties only when editing
    documents, set only the individual nested values that have been
    edited.
  • This does not apply to array item removals, since there is no
    way to perform this (at least in MongoDB 4.0, but doing so
    on newer versions is also not straightforward).
  • Use `$getField` and `$setField` to modify fields whose names
    contain dots or start with a dollar sign.
    This is kind of a breaking change in that, previously, we
    would have queried for the field names containing dots,
    the server would have interpreted the field name as referring
    to nested documents, almost never found a document matching that
    (unless the doc happened to have a shape like
    `
    Unknown macro: { x}

    ` with matching values), and we then
    prompted the user to force-update due to the assumption that
    no document having been found means that it has been updated
    in the background.
    After this change, we just inform users that doing this
    properly requires MongoDB 5.0 or above. Users can still perform
    edits through the JSON view, at least for now (potentially only
    until COMPASS-5753 is done).

  • Split the query/update document generation parts into two steps,
    and move these out of the `Document` class to `ObjectGenerator`
    (which is already a collection of static methods for recursively
    traversing a document/element tree).
  • In the first step, gather all the elements that were updated,
    their original paths and values and their new paths and values.
  • In the second step, build either a query out of those original
    paths and values, or build the update document out of the new
    paths and values.
  • Drive-by bugfixes:
  • When renaming elements, we previously did not check that the
    new name was not already added in the background. We check
    this as well now.
  • Handle the case in which elements are renamed circularly,
    e.g. key2 → key3, key1 → key2 (or similar add/remove situations).
  • Use string arrays instead of objects that are only being used
    to extract their keys in the hadron-document API for hopefully
    a bit more API clarity.
  • Clarify in the docs that dots inside field names refer to
    nested documents. This is the way that sharding behaves,
    which is why we use them in the first place, and is not
    a practical API to break. (And if it does, there is an
    upcoming server sharding project will hopefully already have
    made inclusion of the shard keys unnecessary.)

This also addresses COMPASS-5528 (which is about adjusting the
update document sent to the server, whereas COMPASS-5805 is about
adjusting the query document).
Branch: update-schema-validation-warnings-to-leafygreen
https://github.com/mongodb-js/compass/commit/c865b66bd7c443da8f9d6ab9815aabf98175d8b5

Comment by Githook User [ 14/Jul/22 ]

Author:

{'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}

Message: feat(hadron-document)!: handle nested fields and dots & dollars well COMPASS-5805 (#3239)

  • Instead of fully replacing top-level properties only when editing
    documents, set only the individual nested values that have been
    edited.
  • This does not apply to array item removals, since there is no
    way to perform this (at least in MongoDB 4.0, but doing so
    on newer versions is also not straightforward).
  • Use `$getField` and `$setField` to modify fields whose names
    contain dots or start with a dollar sign.
    This is kind of a breaking change in that, previously, we
    would have queried for the field names containing dots,
    the server would have interpreted the field name as referring
    to nested documents, almost never found a document matching that
    (unless the doc happened to have a shape like
    `
    Unknown macro: { x}

    ` with matching values), and we then
    prompted the user to force-update due to the assumption that
    no document having been found means that it has been updated
    in the background.
    After this change, we just inform users that doing this
    properly requires MongoDB 5.0 or above. Users can still perform
    edits through the JSON view, at least for now (potentially only
    until COMPASS-5753 is done).

  • Split the query/update document generation parts into two steps,
    and move these out of the `Document` class to `ObjectGenerator`
    (which is already a collection of static methods for recursively
    traversing a document/element tree).
  • In the first step, gather all the elements that were updated,
    their original paths and values and their new paths and values.
  • In the second step, build either a query out of those original
    paths and values, or build the update document out of the new
    paths and values.
  • Drive-by bugfixes:
  • When renaming elements, we previously did not check that the
    new name was not already added in the background. We check
    this as well now.
  • Handle the case in which elements are renamed circularly,
    e.g. key2 → key3, key1 → key2 (or similar add/remove situations).
  • Use string arrays instead of objects that are only being used
    to extract their keys in the hadron-document API for hopefully
    a bit more API clarity.
  • Clarify in the docs that dots inside field names refer to
    nested documents. This is the way that sharding behaves,
    which is why we use them in the first place, and is not
    a practical API to break. (And if it does, there is an
    upcoming server sharding project will hopefully already have
    made inclusion of the shard keys unnecessary.)

This also addresses COMPASS-5528 (which is about adjusting the
update document sent to the server, whereas COMPASS-5805 is about
adjusting the query document).
Branch: compass-sidebar-merge
https://github.com/mongodb-js/compass/commit/c865b66bd7c443da8f9d6ab9815aabf98175d8b5

Comment by Githook User [ 13/Jul/22 ]

Author:

{'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}

Message: feat(hadron-document)!: handle nested fields and dots & dollars well COMPASS-5805 (#3239)

  • Instead of fully replacing top-level properties only when editing
    documents, set only the individual nested values that have been
    edited.
  • This does not apply to array item removals, since there is no
    way to perform this (at least in MongoDB 4.0, but doing so
    on newer versions is also not straightforward).
  • Use `$getField` and `$setField` to modify fields whose names
    contain dots or start with a dollar sign.
    This is kind of a breaking change in that, previously, we
    would have queried for the field names containing dots,
    the server would have interpreted the field name as referring
    to nested documents, almost never found a document matching that
    (unless the doc happened to have a shape like
    `
    Unknown macro: { x}

    ` with matching values), and we then
    prompted the user to force-update due to the assumption that
    no document having been found means that it has been updated
    in the background.
    After this change, we just inform users that doing this
    properly requires MongoDB 5.0 or above. Users can still perform
    edits through the JSON view, at least for now (potentially only
    until COMPASS-5753 is done).

  • Split the query/update document generation parts into two steps,
    and move these out of the `Document` class to `ObjectGenerator`
    (which is already a collection of static methods for recursively
    traversing a document/element tree).
  • In the first step, gather all the elements that were updated,
    their original paths and values and their new paths and values.
  • In the second step, build either a query out of those original
    paths and values, or build the update document out of the new
    paths and values.
  • Drive-by bugfixes:
  • When renaming elements, we previously did not check that the
    new name was not already added in the background. We check
    this as well now.
  • Handle the case in which elements are renamed circularly,
    e.g. key2 → key3, key1 → key2 (or similar add/remove situations).
  • Use string arrays instead of objects that are only being used
    to extract their keys in the hadron-document API for hopefully
    a bit more API clarity.
  • Clarify in the docs that dots inside field names refer to
    nested documents. This is the way that sharding behaves,
    which is why we use them in the first place, and is not
    a practical API to break. (And if it does, there is an
    upcoming server sharding project will hopefully already have
    made inclusion of the shard keys unnecessary.)

This also addresses COMPASS-5528 (which is about adjusting the
update document sent to the server, whereas COMPASS-5805 is about
adjusting the query document).
Branch: COMPASS-5673-query-bar
https://github.com/mongodb-js/compass/commit/c865b66bd7c443da8f9d6ab9815aabf98175d8b5

Comment by Githook User [ 13/Jul/22 ]

Author:

{'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}

Message: feat(hadron-document)!: handle nested fields and dots & dollars well COMPASS-5805 (#3239)

  • Instead of fully replacing top-level properties only when editing
    documents, set only the individual nested values that have been
    edited.
  • This does not apply to array item removals, since there is no
    way to perform this (at least in MongoDB 4.0, but doing so
    on newer versions is also not straightforward).
  • Use `$getField` and `$setField` to modify fields whose names
    contain dots or start with a dollar sign.
    This is kind of a breaking change in that, previously, we
    would have queried for the field names containing dots,
    the server would have interpreted the field name as referring
    to nested documents, almost never found a document matching that
    (unless the doc happened to have a shape like
    `
    Unknown macro: { x}

    ` with matching values), and we then
    prompted the user to force-update due to the assumption that
    no document having been found means that it has been updated
    in the background.
    After this change, we just inform users that doing this
    properly requires MongoDB 5.0 or above. Users can still perform
    edits through the JSON view, at least for now (potentially only
    until COMPASS-5753 is done).

  • Split the query/update document generation parts into two steps,
    and move these out of the `Document` class to `ObjectGenerator`
    (which is already a collection of static methods for recursively
    traversing a document/element tree).
  • In the first step, gather all the elements that were updated,
    their original paths and values and their new paths and values.
  • In the second step, build either a query out of those original
    paths and values, or build the update document out of the new
    paths and values.
  • Drive-by bugfixes:
  • When renaming elements, we previously did not check that the
    new name was not already added in the background. We check
    this as well now.
  • Handle the case in which elements are renamed circularly,
    e.g. key2 → key3, key1 → key2 (or similar add/remove situations).
  • Use string arrays instead of objects that are only being used
    to extract their keys in the hadron-document API for hopefully
    a bit more API clarity.
  • Clarify in the docs that dots inside field names refer to
    nested documents. This is the way that sharding behaves,
    which is why we use them in the first place, and is not
    a practical API to break. (And if it does, there is an
    upcoming server sharding project will hopefully already have
    made inclusion of the shard keys unnecessary.)

This also addresses COMPASS-5528 (which is about adjusting the
update document sent to the server, whereas COMPASS-5805 is about
adjusting the query document).
Branch: COMPASS-5672-update-crud-toolbar-to-lg
https://github.com/mongodb-js/compass/commit/c865b66bd7c443da8f9d6ab9815aabf98175d8b5

Comment by Githook User [ 13/Jul/22 ]

Author:

{'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}

Message: feat(hadron-document)!: handle nested fields and dots & dollars well COMPASS-5805 (#3239)

  • Instead of fully replacing top-level properties only when editing
    documents, set only the individual nested values that have been
    edited.
  • This does not apply to array item removals, since there is no
    way to perform this (at least in MongoDB 4.0, but doing so
    on newer versions is also not straightforward).
  • Use `$getField` and `$setField` to modify fields whose names
    contain dots or start with a dollar sign.
    This is kind of a breaking change in that, previously, we
    would have queried for the field names containing dots,
    the server would have interpreted the field name as referring
    to nested documents, almost never found a document matching that
    (unless the doc happened to have a shape like
    `
    Unknown macro: { x}

    ` with matching values), and we then
    prompted the user to force-update due to the assumption that
    no document having been found means that it has been updated
    in the background.
    After this change, we just inform users that doing this
    properly requires MongoDB 5.0 or above. Users can still perform
    edits through the JSON view, at least for now (potentially only
    until COMPASS-5753 is done).

  • Split the query/update document generation parts into two steps,
    and move these out of the `Document` class to `ObjectGenerator`
    (which is already a collection of static methods for recursively
    traversing a document/element tree).
  • In the first step, gather all the elements that were updated,
    their original paths and values and their new paths and values.
  • In the second step, build either a query out of those original
    paths and values, or build the update document out of the new
    paths and values.
  • Drive-by bugfixes:
  • When renaming elements, we previously did not check that the
    new name was not already added in the background. We check
    this as well now.
  • Handle the case in which elements are renamed circularly,
    e.g. key2 → key3, key1 → key2 (or similar add/remove situations).
  • Use string arrays instead of objects that are only being used
    to extract their keys in the hadron-document API for hopefully
    a bit more API clarity.
  • Clarify in the docs that dots inside field names refer to
    nested documents. This is the way that sharding behaves,
    which is why we use them in the first place, and is not
    a practical API to break. (And if it does, there is an
    upcoming server sharding project will hopefully already have
    made inclusion of the shard keys unnecessary.)

This also addresses COMPASS-5528 (which is about adjusting the
update document sent to the server, whereas COMPASS-5805 is about
adjusting the query document).
Branch: COMPASS-5677-update-query-history-toolbar
https://github.com/mongodb-js/compass/commit/c865b66bd7c443da8f9d6ab9815aabf98175d8b5

Comment by Githook User [ 13/Jul/22 ]

Author:

{'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}

Message: feat(hadron-document)!: handle nested fields and dots & dollars well COMPASS-5805 (#3239)

  • Instead of fully replacing top-level properties only when editing
    documents, set only the individual nested values that have been
    edited.
  • This does not apply to array item removals, since there is no
    way to perform this (at least in MongoDB 4.0, but doing so
    on newer versions is also not straightforward).
  • Use `$getField` and `$setField` to modify fields whose names
    contain dots or start with a dollar sign.
    This is kind of a breaking change in that, previously, we
    would have queried for the field names containing dots,
    the server would have interpreted the field name as referring
    to nested documents, almost never found a document matching that
    (unless the doc happened to have a shape like
    `
    Unknown macro: { x}

    ` with matching values), and we then
    prompted the user to force-update due to the assumption that
    no document having been found means that it has been updated
    in the background.
    After this change, we just inform users that doing this
    properly requires MongoDB 5.0 or above. Users can still perform
    edits through the JSON view, at least for now (potentially only
    until COMPASS-5753 is done).

  • Split the query/update document generation parts into two steps,
    and move these out of the `Document` class to `ObjectGenerator`
    (which is already a collection of static methods for recursively
    traversing a document/element tree).
  • In the first step, gather all the elements that were updated,
    their original paths and values and their new paths and values.
  • In the second step, build either a query out of those original
    paths and values, or build the update document out of the new
    paths and values.
  • Drive-by bugfixes:
  • When renaming elements, we previously did not check that the
    new name was not already added in the background. We check
    this as well now.
  • Handle the case in which elements are renamed circularly,
    e.g. key2 → key3, key1 → key2 (or similar add/remove situations).
  • Use string arrays instead of objects that are only being used
    to extract their keys in the hadron-document API for hopefully
    a bit more API clarity.
  • Clarify in the docs that dots inside field names refer to
    nested documents. This is the way that sharding behaves,
    which is why we use them in the first place, and is not
    a practical API to break. (And if it does, there is an
    upcoming server sharding project will hopefully already have
    made inclusion of the shard keys unnecessary.)

This also addresses COMPASS-5528 (which is about adjusting the
update document sent to the server, whereas COMPASS-5805 is about
adjusting the query document).
Branch: COMPASS-5946-leafy-green-select-and-combobox
https://github.com/mongodb-js/compass/commit/c865b66bd7c443da8f9d6ab9815aabf98175d8b5

Comment by Githook User [ 13/Jul/22 ]

Author:

{'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}

Message: feat(hadron-document)!: handle nested fields and dots & dollars well COMPASS-5805 (#3239)

  • Instead of fully replacing top-level properties only when editing
    documents, set only the individual nested values that have been
    edited.
  • This does not apply to array item removals, since there is no
    way to perform this (at least in MongoDB 4.0, but doing so
    on newer versions is also not straightforward).
  • Use `$getField` and `$setField` to modify fields whose names
    contain dots or start with a dollar sign.
    This is kind of a breaking change in that, previously, we
    would have queried for the field names containing dots,
    the server would have interpreted the field name as referring
    to nested documents, almost never found a document matching that
    (unless the doc happened to have a shape like
    `
    Unknown macro: { x}

    ` with matching values), and we then
    prompted the user to force-update due to the assumption that
    no document having been found means that it has been updated
    in the background.
    After this change, we just inform users that doing this
    properly requires MongoDB 5.0 or above. Users can still perform
    edits through the JSON view, at least for now (potentially only
    until COMPASS-5753 is done).

  • Split the query/update document generation parts into two steps,
    and move these out of the `Document` class to `ObjectGenerator`
    (which is already a collection of static methods for recursively
    traversing a document/element tree).
  • In the first step, gather all the elements that were updated,
    their original paths and values and their new paths and values.
  • In the second step, build either a query out of those original
    paths and values, or build the update document out of the new
    paths and values.
  • Drive-by bugfixes:
  • When renaming elements, we previously did not check that the
    new name was not already added in the background. We check
    this as well now.
  • Handle the case in which elements are renamed circularly,
    e.g. key2 → key3, key1 → key2 (or similar add/remove situations).
  • Use string arrays instead of objects that are only being used
    to extract their keys in the hadron-document API for hopefully
    a bit more API clarity.
  • Clarify in the docs that dots inside field names refer to
    nested documents. This is the way that sharding behaves,
    which is why we use them in the first place, and is not
    a practical API to break. (And if it does, there is an
    upcoming server sharding project will hopefully already have
    made inclusion of the shard keys unnecessary.)

This also addresses COMPASS-5528 (which is about adjusting the
update document sent to the server, whereas COMPASS-5805 is about
adjusting the query document).
Branch: main
https://github.com/mongodb-js/compass/commit/c865b66bd7c443da8f9d6ab9815aabf98175d8b5

Comment by Githook User [ 11/Jul/22 ]

Author:

{'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}

Message: feat(hadron-document)!: handle nested fields and dots & dollars well COMPASS-5805

  • Instead of fully replacing top-level properties only when editing
    documents, set only the individual nested values that have been
    edited.
  • This does not apply to array item removals, since there is no
    way to perform this (at least in MongoDB 4.0, but doing so
    on newer versions is also not straightforward).
  • Use `$getField` and `$setField` to modify fields whose names
    contain dots or start with a dollar sign.
    This is kind of a breaking change in that, previously, we
    would have queried for the field names containing dots,
    the server would have interpreted the field name as referring
    to nested documents, almost never found a document matching that
    (unless the doc happened to have a shape like
    `
    Unknown macro: { x}

    ` with matching values), and we then
    prompted the user to force-update due to the assumption that
    no document having been found means that it has been updated
    in the background.
    After this change, we just inform users that doing this
    properly requires MongoDB 5.0 or above. Users can still perform
    edits through the JSON view, at least for now (potentially only
    until COMPASS-5753 is done).

  • Split the query/update document generation parts into two steps,
    and move these out of the `Document` class to `ObjectGenerator`
    (which is already a collection of static methods for recursively
    traversing a document/element tree).
  • In the first step, gather all the elements that were updated,
    their original paths and values and their new paths and values.
  • In the second step, build either a query out of those original
    paths and values, or build the update document out of the new
    paths and values.
  • Drive-by bugfixes:
  • When renaming elements, we previously did not check that the
    new name was not already added in the background. We check
    this as well now.
  • Handle the case in which elements are renamed circularly,
    e.g. key2 → key3, key1 → key2 (or similar add/remove situations).
  • Use string arrays instead of objects that are only being used
    to extract their keys in the hadron-document API for hopefully
    a bit more API clarity.
  • Clarify in the docs that dots inside field names refer to
    nested documents. This is the way that sharding behaves,
    which is why we use them in the first place, and is not
    a practical API to break. (And if it does, there is an
    upcoming server sharding project will hopefully already have
    made inclusion of the shard keys unnecessary.)

This also addresses COMPASS-5528 (which is about adjusting the
update document sent to the server, whereas COMPASS-5805 is about
adjusting the query document).
Branch: 5805-dev
https://github.com/mongodb-js/compass/commit/029c55f74c5e411558faf9f15e955d4c769fe905

Comment by Githook User [ 11/Jul/22 ]

Author:

{'name': 'Anna Henningsen', 'email': 'anna.henningsen@mongodb.com', 'username': 'addaleax'}

Message: feat(hadron-document)!: handle nested fields and dots & dollars well COMPASS-5805

  • Instead of fully replacing top-level properties only when editing
    documents, set only the individual nested values that have been
    edited.
  • This does not apply to array item removals, since there is no
    way to perform this (at least in MongoDB 4.0, but doing so
    on newer versions is also not straightforward).
  • Use `$getField` and `$setField` to modify fields whose names
    contain dots or start with a dollar sign.
    This is kind of a breaking change in that, previously, we
    would have queried for the field names containing dots,
    the server would have interpreted the field name as referring
    to nested documents, almost never found a document matching that
    (unless the doc happened to have a shape like
    `
    Unknown macro: { x}

    ` with matching values), and we then
    prompted the user to force-update due to the assumption that
    no document having been found means that it has been updated
    in the background.
    After this change, we just inform users that doing this
    properly requires MongoDB 5.0 or above. Users can still perform
    edits through the JSON view, at least for now (potentially only
    until COMPASS-5753 is done).

  • Split the query/update document generation parts into two steps,
    and move these out of the `Document` class to `ObjectGenerator`
    (which is already a collection of static methods for recursively
    traversing a document/element tree).
  • In the first step, gather all the elements that were updated,
    their original paths and values and their new paths and values.
  • In the second step, build either a query out of those original
    paths and values, or build the update document out of the new
    paths and values.
  • Drive-by bugfixes:
  • When renaming elements, we previously did not check that the
    new name was not already added in the background. We check
    this as well now.
  • Handle the case in which elements are renamed circularly,
    e.g. key2 → key3, key1 → key2 (or similar add/remove situations).
  • Use string arrays instead of objects that are only being used
    to extract their keys in the hadron-document API for hopefully
    a bit more API clarity.
  • Clarify in the docs that dots inside field names refer to
    nested documents. This is the way that sharding behaves,
    which is why we use them in the first place, and is not
    a practical API to break. (And if it does, PM-1632 will
    hopefully already have made inclusion of the shard keys
    unnecessary.)

This also addresses COMPASS-5528 (which is about adjusting the
update document sent to the server, whereas COMPASS-5805 is about
adjusting the query document).
Branch: 5805-dev
https://github.com/mongodb-js/compass/commit/148cc77f498c5d2ea02d5682451c90d5d3aeece7

Comment by Massimiliano Marcon [ 14/Mar/22 ]

ataramina@shorecg.com thank you for opening this issue. Unfortunately, this improvement is not as straightforward as it may seem.

I do, however, see how this is useful and important in the context of testing out change streams so we'll keep this ticket open and see when we can prioritize it.

Generated at Wed Feb 07 22:39:53 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.