Previous version of the test relied on a single extremely large query
(close to 16MB). Unfortunately, extremely large queries have their own
problems, which are not related to query settings
GitOrigin-RevId: 597c0b62073e92236ddaccf2460d408ed6c49b1e
Persistent query settings should not apply to queries with encryption
information to minimize possible attack space:
- unintentionally exposing encrypted attribute values, types or
cardinality
- using persistent query settings to guess the shapes of encrypted
queries
GitOrigin-RevId: 294116f3e3ef85bfa7b4fd66df7469104a92e1d4
Until this change 'removeQuerySettings' would throw when the setting is
not found. With this behaviour 'removeQuerySettings' cannot be re-tried,
which causes problems in test infrastructure. Therefore we have decided
not to throw when the settings was not found.
GitOrigin-RevId: fd2ff323d5831eedeb130609097d4fbdc49d238e
When slow queries are printed into the log they can be truncated and
therefore cannot be used in the 'setQuerySettings' command. To avoid
this we allow adding new query settings only by hash without a
representative query.
GitOrigin-RevId: 18f4c9edbc7f04ea10d02eeca5781094174995b0
SERVER-79231 Apply QuerySettings for aggregate commands with $lookup
This patch ensures that query settings are applied on aggregate
commands, including the commands that contain $lookup stages.
QueryPlannerParams::fillOutSecondaryCollectionsPlannerParams() is marked
as private, such that clients can only call fillOutPlannerParams() in
order to populate the QueryPlannerParams.
GitOrigin-RevId: e22a78c7fc5f9c16ce4989179b635c9065932581
SERVER-85876
Reject requests matching QuerySettings with reject=true
If an admin has set reject in QuerySettings matching an incoming
find/agg/distinct, the request should be failed.
However, explaining such a query is comparatively cheap and is useful
as a debugging tool. As such, explains for such queries should still be
permitted.
GitOrigin-RevId: ca54838c041844066760e2dadf682e6a05679260
This patch makes sure that corresponding query settings appear in the
explain of the aggregate commands, if those commands have query settings
set. This includes adding 'querySettings' to the aggregate command idl
as well as propagating the query settings from mongos to the shards in
sharded cluster deployment.
GitOrigin-RevId: 9ad100fc9ecb2053db6e07950bd988a0deef1180
Cluster parameter values are cached on routers = mongoS and updated (pulled)
from the config-servers periodically by the 'ClusterServerParameterRefresher'
background job. This means, the new cluster parameter value will not be cached
immediately, but after some delay. This delay is problematic for the
'querySettings' cluster parameter which has read-modify-write updates, because
subsequent 'setQuerySettings' or 'removeQuerySettings' commands might have
a non-deterministic outcome. This change minimizes the delay by forcing
'ClusterServerParameterRefresher' iterations before and after the modification.
Before this change, query settings were only looked up on mongod, which means that query settings will not be applied to find queries that were modified on mongos. In order to fix this issue, query settings will be looked up on mongos in sharded cluster and on mongod in replica set deployments. Upon the lookup, query settings will be propagated to the shards as command's new 'querySettings' attribute (marked as unstable).
In addition, as a part of this change, the encoding of a CanonicalQuery into a QueryShapeString will omit the 'hint' field if it is made redundant by the matching query setting.
Before this change, query settings were only looked up on mongod, which means that query settings will not be applied to find queries that were modified on mongos. In order to fix this issue, query settings will be looked up on mongos in sharded cluster and on mongod in replica set deployments. Upon the lookup, query settings will be propagated to the shards as command's new 'querySettings' attribute (marked as unstable).
In addition, as a part of this change, the encoding of a CanonicalQuery into a QueryShapeString will omit the 'hint' field if it is made redundant by the matching query setting.
Before this change, query settings were only looked up on mongod, which means that query settings will not be applied to find queries that were modified on mongos. In order to fix this issue, query settings will be looked up on mongos in sharded cluster and on mongod in replica set deployments. Upon the lookup, query settings will be propagated to the shards as command's new 'querySettings' attribute (marked as unstable).
In addition, as a part of this change, the encoding of a CanonicalQuery into a QueryShapeString will omit the 'hint' field if it is made redundant by the matching query setting.
Due to timing issue it may happen that `removeAllQuerySettings()` doesn't remove
"all" query settings, because at the moment of deletion, not all of them are
present on mongos.
This patch resolves this issue, by asserting that the newly inserted query
settings are present on mongos as well as ensuring that the query settings are
no longer present upon deletion.
'querySettings' field is added to the explain output.
QueryShapeHash is lazily computed on QuerySettings lookup. The hash is computed
only in cases when there is at least on query settings set for a given tenant.
Until now, a new value of a cluster parameter was just replacing the old one.
For the query settings project it is important to read / modify / write
cluster parameter values. In this scenario, concurrent calls of
'setQuerySettings' command may lead to seemingly successful, but incorrect
results.
This change introduces an additional 'previousTime' parameter to ensure
that the cluster parameter value that was read has not changed at the time
of writing, otherwise the operation must fail.
