8 results found

1. Support change streams without service discovery

   Currently, change streams are not supported in standalone instances, so testing change stream functionality requires a one-node replica set. However, promoting a standalone node to a one-node replica set requires a call to rs.initiate(config), which requires host and port information so that clients can connect; something that is not required for standalone nodes. This means change stream support is conflated with service discovery. It becomes impossible, for example, to create a docker image that boots as a single-node replica set, while it's trivial to make a docker image that boots as a standalone server.

   Various ideas that would make this easier:

   1. Support change streams in standalone nodes. While it's understandable that standalone nodes don't support change streams because they have no oplog, this is still a rather major omission in the functionality of standalone nodes.

   2. Make rs.initiate() (with no configuration) default to a single-node cluster that clients connect to using the host and port from their connection string. (Current behaviour defaults to "localhost:27017" which is risky, since it can cause two separate single-node replica sets to be quietly interconnected if one of them happens to be on localhost:27017.)

   Currently, change streams are not supported in standalone instances, so testing change stream functionality requires a one-node replica set. However, promoting a standalone node to a one-node replica set requires a call to rs.initiate(config), which requires host and port information so that clients can connect; something that is not required for standalone nodes. This means change stream support is conflated with service discovery. It becomes impossible, for example, to create a docker image that boots as a single-node replica set, while it's trivial to make a docker image that boots as a standalone server.

   Various ideas that would make… more

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Change Streams  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. add view，index，user，role to mongodb Change Stream

   I tested the changeStream of mongodb. The changes of adding view, index, user and role to mongodb are not reflected in changeStream, but the corresponding log can be found in oplog. I have an issue on https://jira.mongodb.org/browse/SERVER-66460 and got it confirmed, but Chris Kelly thinks this should be a feature. Hopes to add this feature in future versions

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Change Streams  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Get metadata about source client connection that submitted a given change

   Currently with change streams it is impossible to know who or what connection initiated the changes.

   It would be a good feature to have to be able to receive some data about the source client connection that initiated a change.

   My particular use case is the following:

   I have an app that connects to Atlas. (source client connection)
   I can subscribe to change streams and then execute some logic when it applies.

   That app can scale to multiple instances.
   Each instance subscribes to the change streams.
   But I only want each instance to execute the logic that applies to only events that they have initiated through their own connection.

   Right now it seems impossible and the only way to do so would be to generate a unique App ID for each instance and log it in a separate collection for each change and subscribe to that. Although this would work, it would be simpler to have this feature built-in without the need for a separate collection.

   Maybe this could be good for other use cases.

   Another use case that I can think of, is the following:

   If a change is done in a collection that is not made by the source client connection, then apply some logic.

   For example: my app instance would execute some logic when data was manipulated outside my app, either manually or by third parties.

   Hope I am being clear, thanks!

   Currently with change streams it is impossible to know who or what connection initiated the changes.

   It would be a good feature to have to be able to receive some data about the source client connection that initiated a change.

   My particular use case is the following:

   I have an app that connects to Atlas. (source client connection)
   I can subscribe to change streams and then execute some logic when it applies.

   That app can scale to multiple instances.
   Each instance subscribes to the change streams.
   But I only want each instance to execute the logic that applies to only… more

   5 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Change Streams  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Change streams and Triggers for Time Series Collections

   Add Change streams and Trigger capabilities to Time Series Collections.
   Current Limitations don't allow this.
   https://docs.mongodb.com/manual/core/timeseries/timeseries-limitations/#change-streams

   13 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   planned  ·  1 comment  ·  Change Streams  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Old and New values in change tracking

   Change streams currently return only the new version of the documents.

   If there were an option that could be set on the collection for the change streams to also return the old version of the document, it would simplify any business logic that requires the old version.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   started  ·  1 comment  ·  Change Streams  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Ability to create the resume token based on oplog item

   CHoose an oplog event to set the resume token for, instead of needing to run the change stream for system to create a resume token

   Why: Concerns about many stream re-reading a full oplog if failure before finding first event

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Change Streams  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. Low latency Change Stream for Global Cluster in Atlas

   our event-driven applications need to publish events to Kafka triggered by Change Stream feature. It works perfect in replicaset MongoDB cluster.

   However, after migrating to Global Cluster in Atlas, the Change Stream cannot keep low latency because of ordering reason among shards.
   The latency may go up to 20 seconds when for a single change event.

   It would be nice if application can receive Change Stream from the single shard only (not care about ordering among shards) to prevent latency.

   The idea is to pass "location" options when starting the Change Stream cursor.

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Change Streams  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Include schema validation events in changestream payload

   let's say my document has JSON schema validation like:

   {
     $jsonSchema: {
       properties: {
         phone: {
           bsonType: 'string'
         }
       }
     }
   }
   

   and the validation action is set to "warning", if I do a command like: db.test.insert({"phone":1}), I would like the warning message to be included in my change stream.

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Change Streams  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close