Conversation
the next generation of cosmosdb is supposed to be more efficient as the current one. local tests with this generation showed lower CPU usage and also does not require partition configuration. Signed-off-by: Gerd Oberlechner <goberlec@redhat.com>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: geoberle The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: Gerd Oberlechner <goberlec@redhat.com>
geoberle
force-pushed
the
cosmos-emulator-vnext
branch
from
9ad6aa4 to
926b275
Compare
| } | ||
|
|
||
| allContainers := sets.NewString() | ||
| allContainersQuery := cosmosDatabaseClient.NewQueryContainersPager("select * from containers c", nil) |
There was a problem hiding this comment.
NewQueryContainersPager is not supported in vnext
we can rely on cosmosDatabaseClient.CreateContainer to give us a StatusConflict in case the container exists already
|
/test integration |
19 similar comments
|
/test integration |
|
/test integration |
|
/test integration |
|
/test integration |
|
/test integration |
|
/test integration |
|
/test integration |
|
/test integration |
|
/test integration |
|
/test integration |
|
/test integration |
|
/test integration |
|
/test integration |
|
/test integration |
|
/test integration |
|
/test integration |
|
/test integration |
|
/test integration |
|
/test integration |
1 participant
What
the next generation of cosmosdb is supposed to be more efficient as the current one. local tests with this generation showed lower CPU usage and also does not require partition configuration.
what vnext can't do: query it's own containers, so we rely on the conflict error to notice if container creation failed because it exists already
in testing: CI will tell us if this helps our intermittent issues :(
Why
Special notes for your reviewer