[SERVER-85855] Creating a bucket collection with timeseries option doesn't create the view Created: 29/Jan/24 Updated: 01/Feb/24 |
|
| Status: | Needs Scheduling |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Enrico Golfieri | Assignee: | Backlog - Catalog and Routing |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Catalog and Routing
|
|||||||||
| Operating System: | ALL | |||||||||
| Steps To Reproduce: |
|
|||||||||
| Participants: |
| Description |
|
Currently creating a bucket collection "test.system.buckets.coll" with timeseries options creates the collection as a timeseries but doesn't create the related view. As a consequence, creating another collection with the view namespace "test.coll" works. This is problematic because any reference to "test.coll" is now routed to the bucket namespace, causing all the insert to fail as they require the "timestamp" field. However, writing in that collection is not safe, and even a insert using the "expected" format will cause the primary node to crash Possible solution: A solution could be to force the creation of the related view when a user inserts a bucket collection with timeseries options. This would simplify the reasoning behind creating a collection which is supposed to be internal. This would also cause the second create to return NamespaceExists and solve this specific bug. Note this refers specifically to a bucket namespace with timeseries options, without the timeseries options the collection should be treated as a normal collection. |