Jacob
My feedback
17 results found
-
5 votesJacob
supported this idea
·
-
5 votesJacob
shared this idea
·
-
4 votesJacob
supported this idea
·
-
16 votes
An error occurred while saving the comment Jacob
supported this idea
·
-
5 votesJacob
shared this idea
·
-
13 votesJacob
supported this idea
·
An error occurred while saving the comment Jacob
commented
The mongodbatlas terraform provider allows the creation of triggers but they require an app id and "config service id". The app id refers to the id of an app services application and the config service id is a linked data source. You cannot create an app services app or linked data source using the terraform provider and therefore you cannot create triggers with the provider alone. The provider should be updated to allow the creation of the app_id and config_service_id objects.
-
11 votesJacob
supported this idea
·
-
6 votesJacob
shared this idea
·
-
8 votesJacob
shared this idea
·
-
11 votesJacob
supported this idea
·
-
461 votesJacob
supported this idea
·
-
6 votesJacob
supported this idea
·
-
32 votesJacob
supported this idea
·
-
12 votesJacob
supported this idea
·
-
10 votesJacob
supported this idea
·
-
167 votesJacob
supported this idea
·
-
12 votesJacob
shared this idea
·
> Dropping indexes does not have a comparable operational impact, so you can do those with direct MongoDB wire protocol access to the cluster itself (you can do the same with building indexes where a traditional foreground or background index build suffices).
Not necessarily. Many desired state configurations do not have direct wire protocol access and thus require this type of functionality via the administrative API.
At a bare minimum there should also be a method to read the current state of indexes via the API. An update can be satisfied via a delete and create. These endpoints should exist please revisit.