[SERVER-60020] Remove special handling for cases when only time-series view exists Created: 16/Sep/21 Updated: 27/Dec/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Nikita Lapkov (Inactive) | Assignee: | Backlog - Query Integration |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | neweng, qi-timeseries, read-only-views, tscs-ramp | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Query Integration
|
||||||||
| Participants: | |||||||||
| Description |
|
At the moment of writing, there can be a situation when time-series view exists, but time-series buckets collection does not. This can happen when the user directly drops time-series buckets collection, for example. For such situations, we have special handling in multiple places. See listCollections command as an example. After |
| Comments |
| Comment by Gregory Noma [ 02/Jul/22 ] |
|
I don't think we can block FCV upgrade like that. For instance imagine a serverless environment; it wouldn't be acceptable to block FCV upgrade because of one tenant on that cluster. An alternative could be to create a sort of "default" buckets collection during FCV upgrade in that scenario, but that idea has some issues as well. One issue would be what to use for timeField which is required to be specified by the user upon time-series collection creation. Worse yet, what if there's a collection that "looks like" a corresponding buckets collection based on its name, but doesn't actually have the correct options to be a buckets collection? |
| Comment by Mickey Winters [ 01/Jul/22 ] |
|
yeah I agree with the fcv check, we need to do this at some point so we aren't permanently stuck worrying about the scenario greg pointed out |
| Comment by Jennifer Peshansky (Inactive) [ 01/Jul/22 ] |
|
I think we should do this as part of FCV upgrade behavior. When a user attempts to upgrade their FCV, we check for a timeseries view without an underlying buckets collection (and probably the inverse, a buckets collection without a timeseries view) and block FCV upgrade until they delete the offending collection/view(s). This would also solve a similar issue Note that since |
| Comment by Gregory Noma [ 28/Jun/22 ] |
|
In terms of what this ticket is currently proposing, I'm actually not sure if there's much we can do here since a user could have always gotten into this state before we did |
| Comment by Mickey Winters [ 28/Jun/22 ] |
|
gregory.noma@mongodb.com potentially should we be checking that as part of some startup task to check integrity? |
| Comment by Gregory Noma [ 11/Oct/21 ] |
|
One thing we may need to take into consideration here is the case where someone dropped only the buckets collection before we made doing so also drop the view. |