|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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.