[SERVER-29580] Create a $_internalSchemaPatternProperties MatchExpression Created: 12/Jun/17  Updated: 21/Jul/17  Resolved: 21/Jul/17

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Kyle Suarez Assignee: Natalia Jacobowitz
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Query 2017-07-10, Query 2017-07-31
Participants:

 Description   
Proposed Syntax

$_internalSchemaPatternProperties imposes sub-schemas on fields of an object, based on whether or not they match a regex. It has the following form:

{ $_internalSchemaPatternProperties: <regex-expression-list> }

<regex-expression-list> has the following form:

[
    {regex: <regex>, expression: <MatchExpression>},
    ....
]

To constrain a subobject, wrap it in an $objectMatch:

{ <field>: $objectMatch: { $_internalSchemaPatternProperties: <regex-expression-list> } }



 Comments   
Comment by Natalia Jacobowitz [ 21/Jul/17 ]

Pattern properties is being absorbed in the $_internalSchemaAllowedProperties match expression.

Comment by David Storch [ 22/Jun/17 ]

As discussed in person, $_internalSchemaObjectMatch fixes the top-level only problem. We also discussed changing the format to this:

{$_internalSchemaPatternProperties: [{regex: <regex>, expression: <MatchExpression>}, ...]}

Comment by Kyle Suarez [ 22/Jun/17 ]

First, regarding the regex flags: In JSON Schema land, the "regex keys" must be specified as strings. How would you specify flags in a string? Can PCRE properly parse the string

"/[a-z]+/i"

into the regex

/[a-z]+/i

or does it literally interpret the slashes? I'm looking at other implementations to see how they approach this particular problem, though when I was looking at example schemas, I hadn't seen any that use flags in patternProperties.

Second, I think being top-level only is not an option. In JSON Schema, this is allowed at any level.

{
    patternProperties: {
        "^address": {
            patternProperties: {
                "^street": {...},
                "^avenue": {...},
            }
        },
        "^phone": {...}
    }
}

Comment by David Storch [ 22/Jun/17 ]

The <regex-map-object> part might be problematic, since it encodes a regular expression inside a BSON field name. According to the JSON Schema spec section 6.19:

Each property name of this object SHOULD be a valid regular expression, according to the ECMA 262 regular expression dialect.

As far as I can tell from https://www.ecma-international.org/ecma-262/5.1/#sec-7.8.5, this means that the regular expression can contain both a body and flags, as in /body/flags. kyle.suarez, does this sound right to you? If so, I think we need this to be an array of two-element arrays. For example,

{$_internalSchemaPatternProperties: [[/^foo/i, <MatchExpression>], [/bar$/i, <MatchExpression>]]}

Another concern is that I don't think this should ever come after a path name, as in { <field>: { $_internalSchemaPatternProperties: <regex-map-object> } }. Instead, I think this should always be top-level, in the sense that in the grammar it is a sibling of expressions like $or and $and.

Generated at Thu Feb 08 04:21:16 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.