PHPLIB-242: Refactor command operations to use field path syntax for type maps #658
Conversation
alcaeus
force-pushed
the
phplib-242
branch
2 times, most recently
from
d68d5d2 to
6445c3a
Compare
src/functions.php
Outdated
| */ | ||
| function create_field_path_type_map(array $typeMap, $fieldPath) | ||
| { | ||
| if (isset($typeMap['root']) && ! isset($typeMap['fieldPaths'][$fieldPath])) { |
There was a problem hiding this comment.
Should we skip this just because the user has specified both a custom root type and happens to have specified our internal field path in their own fieldPaths option?
For instance, if we're using this with FindAndModify and the user specified a custom type for the value field path, I imagine we should just move that to the value.value field path. And independent of that, whatever the user specifies for root can always can always be assigned to $typeMap['fieldPaths'][$fieldPath] at the end (as you do later in the function).
I wonder if it'd make sense to just handle these independently.
There was a problem hiding this comment.
You are correct. The helper function now always nests all pre-existing field paths to prefix them with the given field path. It also applies an object type for the root key, and an array type for the array key if the given field path ends in .$. This was added because the Aggregate, Distinct, and MapReduce operations expect an array of results instead of an iterator. We may always optimise this further down the road by returning an iterator directly instead of wrapping the results after the call. For now, this works just fine though.
alcaeus
force-pushed
the
phplib-242
branch
2 times, most recently
from
3f35d48 to
2071922
Compare
| } | ||
|
|
||
| if ( ! is_object($result->value)) { | ||
| throw new UnexpectedValueException('findAndModify command did not return a "value" document'); |
There was a problem hiding this comment.
Do we no longer need to throw this exception?
There was a problem hiding this comment.
findAndModify will either return a document or null depending on the operation and matched values. We're guarding against a missing value property in the return statement, but from what I can see we don't need to guard against non-object values being returned from findAndModify.
This adds a new internal function to modify a type map given to a command and add a
fieldPathtype for the given path. This is used in theAggregate,Distinct,FindAndModify, andMapReduceoperations to avoid manually applying the type map to the results. Any pre-existing field paths are prefixed with the internal field path to ensure consistent results. If a user already passes a type for the field path for the given operation, it is not overwritten as I assume the user "knows what they are doing". The root type is always set toobject; otherwise the user would be able to break internal functionality by changing the root type. I'm not sure whether the name of the function is appropriate to convey what the function is doing; I'm open to suggestions in this regard.