nickva commented on code in PR #6080:
URL: https://github.com/apache/couchdb/pull/6080#discussion_r3819298503
##########
src/mango/src/mango_selector.erl:
##########
@@ -548,22 +689,139 @@ match({[{<<"$", _/binary>> = Op, _}]}, _, _) ->
% We need to traverse value to find field. The call to
% mango_doc:get_field/2 may return either not_found or
% bad_path in which case matching fails.
-match({[{Field, Cond}]}, Value, Cmp) ->
+match({[{Field, Cond}]}, Value, #ctx{verbose = Verb, path = Path} = Ctx) ->
+ InnerPath = extend_path(Field, Path),
Review Comment:
If we extend even for non-verbose case we should benchmark a few case which
exercise this path with verbose=false (default) with before and after the PR
##########
src/docs/src/config/couchdb.rst:
##########
@@ -258,6 +258,19 @@ Base CouchDB Options
[couchdb]
js_engine = spidermonkey
+ .. config:option:: validate_vdu :: Enable checking of
``validate_doc_update``
+
+ .. versionadded:: TODO
+
+ When set to ``true``, the ``validate_doc_update`` field will be
+ validated when design documents are updated. For ``javascript`` design
Review Comment:
For "javascript" (default) language only. "query" is always validated.
##########
test/elixir/test/config/suite.elixir:
##########
@@ -526,12 +526,18 @@
"JavaScript VDU rejects an invalid document",
"JavaScript VDU accepts a valid change",
"JavaScript VDU rejects an invalid change",
+ "invalid JavaScript VDU is detected on doc update",
+ "invalid JavaScript VDU is rejected on design doc update",
"Mango VDU accepts a valid document",
"Mango VDU rejects an invalid document",
"updating a Mango VDU updates its effects",
"converting a Mango VDU to JavaScript updates its effects",
"deleting a Mango VDU removes its effects",
"Mango VDU rejects a doc if any existing ddoc fails to match",
+ "invalid Mango VDU is detected on doc update",
Review Comment:
This test was removed but we left the title in it seems. Maybe it can be a
test of a "query" VDU language but the function is a javascript string one (or
just any string) or other type.
##########
src/mango/src/mango_selector.erl:
##########
@@ -299,9 +321,16 @@ norm_negations({[{<<"$or">>, Args}]}) ->
norm_negations({[{<<"$elemMatch">>, Arg}]}) ->
{[{<<"$elemMatch">>, norm_negations(Arg)}]};
norm_negations({[{<<"$allMatch">>, Arg}]}) ->
- {[{<<"$allMatch">>, norm_negations(Arg)}]};
+ Out = norm_negations(Arg),
+ {[{<<"$allMatch">>, Out}]};
norm_negations({[{<<"$keyMapMatch">>, Arg}]}) ->
{[{<<"$keyMapMatch">>, norm_negations(Arg)}]};
+% Sometimes a top-level key will be a doc field because it
+% can't be pushed down through its corresponding operator,
+% e.g. {x: {$allMatch: S}}. Negation inside the $allMatch
+% should still be normalized.
+norm_negations({[{Field, Cond}]}) when is_list(Field) ->
Review Comment:
This is a behavior change in indexing/filtering? And I think it applies to
non-verbose case too? It's a bug fix but we could still call it out (maybe
someone relied on the bug for indexing/filtering).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
