[COMPASS-5753] JSON editor is the only way to change _id Created: 19/Apr/22  Updated: 30/Aug/22

Status: Open
Project: Compass
Component/s: CRUD
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Anna Henningsen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to COMPASS-5528 Compass replaces whole array if you u... Closed
related to COMPASS-4345 Compass does a replace instead of an ... Closed
Story Points: 8
Sprint: Iteration Eel

 Description   

Since COMPASS-4345, Compass uses findOneAndUpdate to modify documents in the document/table views, and findOneAndReplace in the JSON view. That means that only the JSON view supports changing _id, which is not necessarily obvious or intuitive.

See: https://github.com/mongodb-js/compass/issues/2960#issuecomment-1100053941



 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

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