|
When watch a database containing a time-series collection, this is the current behavior:
foo:PRIMARY> dbcs = db.watch()
|
foo:PRIMARY> dbcs.hasNext()
|
false
|
foo:PRIMARY> db.ts.insert({_id: 2, tm: ISODate(), mm: 'bbbb'})
|
WriteResult({ "nInserted" : 1 })
|
foo:PRIMARY> dbcs.hasNext()
|
false
|
|
|
The error for the system collection is from SERVER-34086 in DocumentSourceChangeStream::assertIsLegalSpecification().
|
|
The error returned for db.ts.watch() is from changes made in SERVER-53963 to the aggregate command.
|
|
Current behavior observed on master at commit e71f3e197153adb28dbfa681074f15fa60ae2473:
foo:PRIMARY> tscs = db.ts.watch()
|
uncaught exception: Error: command failed: {
|
"ok" : 0,
|
"errmsg" : "Namespace test.ts is a timeseries collection",
|
"code" : 166,
|
"codeName" : "CommandNotSupportedOnView",
|
"$clusterTime" : {
|
"clusterTime" : Timestamp(1621968915, 2),
|
|
foo:PRIMARY> tscs = db.system.buckets.ts.watch()
|
uncaught exception: Error: command failed: {
|
"ok" : 0,
|
"errmsg" : "$changeStream may not be opened on the internal test.system.buckets.ts collection",
|
"code" : 73,
|
"codeName" : "InvalidNamespace",
|
|
|
|
|
geert.bosch can we expand the scope of this to also make sure we reject with an appropriate error when a user tries to open a change stream on a time-series collection? We should think about and test opening a change stream on the "system.buckets" version, I don't have a strong opinion there but I would lean towards rejecting such requests until we have a clear guidance or use case.
These seem like very related topics to the title/description, but I interpreted what you wrote so far as testing what change streams with a broader scope such as whole-db or whole-cluster change streams do with the system.buckets collection. Is that what you had in mind?
|
Generated at Thu Feb 08 05:35:23 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.