PHPLIB-1271 Add tests from the documentation

[GromNaN]

• In generator config, create files <operator>.tests.js to store a list of expected pipelines.

• Use a Node script to convert the JS to PHP array

• Add tests: item operators config Yaml files.

• Generate a PHPUnit test class for each operator.

[GromNaN]

Required to modify existing files with the generator.

[GromNaN]

This pipeline can't be implemented. Work on $sum operator is required. PHPLIB-1287

[jmikola]

If I understand correctly, only the get methods are generated and you still need to write the test yourself. Rather than embed generated methods within non-generated files, why not just generate JSON files which are then referenced from these tests?

Alternatively, you can generate actual PHP files that return the value to compare against. I suppose that could be either an array or MongoDB\BSON\PackedArray instance.

[jmikola]

I assume this is the first use of this function. If we keep it as-is, renaming $expected to $expectedJson may be clearer. I do think it may be preferable to avoid JSON entirely and just generate PHP files that return a value that can be included here.

Those generated files could then have the appropriate "auto-generated" header and be ignored via .gitattributes.

[GromNaN]

$regex is a special key. I can't use it for a regular object.

$json = <<<'JSON'
{
    "foo": {
        "$regex": {
            "$regularExpression": {
                "pattern": "789$",
                "options": "i"
            }
        }
    }
}
JSON;

$document = fromJSON($json);

// Fatal error: Uncaught MongoDB\Driver\Exception\UnexpectedValueException: Unexpected nested object value for "$regex" key 

[jmikola]

That exception originates from _bson_json_read_start_map()

Also discussed in the Extended JSON spec:

• Parsers
• Of Canonical Type Wrapper Formats: RegularExpression
• Q&A

If you're using $regex as a query operator, the "Parsers" section above says:

A parser that accepts Legacy Extended JSON MUST be configurable such that a JSON text of a MongoDB query filter containing the regex query operator can be parsed.

And then it proceeds to give two examples. The first example resembles what you're trying to do here, where the $regex value is the extended JSON representation of a regex object (using the $regularExpression key). I'm not sure why that's prohibited in libbson, but it may be worth asking the C team about.

That aside, is anything preventing you from using the following?

{ $regex: 'pattern', $options: '<options>' }

[GromNaN]

That aside, is anything preventing you from using the following?
{ $regex: 'pattern', $options: '<options>' }

This will result in new MongoDB\BSON\Regex('pattern', '<options'>).

The codec wraps the regex in the $regex operator for consistency with other operators.

The expected query that I need to encode in Yaml/Json is:

(object) ['sku' => (object) ['$regex' => new MongoDB\BSON\Regex('789$', '')]]

[GromNaN]

$query = (object) ['sku' => (object) ['$regex' => new MongoDB\BSON\Regex('789$', '')]];

$json = MongoDB\BSON\toJSON(MongoDB\BSON\fromPHP($x));

// { "sku" : { "$regex" : { "$regex" : "789$", "$options" : "" } } }

MongoDB\BSON\fromJSON($json);

// Warning: Uncaught MongoDB\Driver\Exception\UnexpectedValueException: Unexpected nested object value for "$regex" key in php shell code:1

[GromNaN]

Issue solved by comparing JSON: #13

[alcaeus]

Changes LGTM. No objection to using JSON for pipelines until we're able to read JSON pipelines into BSON without encountering parsing issues. 👍