Question about fieldPaths (feature request?)

[719media]

Clarification on fieldPaths, if a document with structure something like:

// 
{
  name: 'test',
  relationships: [
    { type: 'person', age: 32 },
    { type: 'asset', value: 15 }
  ],
}

was queried with a typeMap of

'typeMap' => [
  'root' => 'MyProject\MyClass',
  'array' => 'array',
  'document' => 'array',
  'fieldPaths' => [
    'relationships' => 'MyProject\MyRelationship'
  ],
],

That all works as expected. But, what if you wanted to use a different class depending on the type value? I understand if I had control of the schema, I could potentially use __pclass property... but in the scenario where the schema is fixed, could a different method be used? It doesn't seems like the fieldPaths option has any more verbose logic to use a field name to interpret the class... but perhaps there would be the ability to have the __pclass property able to be specified at query type? So something like

'typeMap' => [
  'root' => 'MyProject\MyClass',
  'array' => 'array',
  'document' => 'array',
  'fieldPaths' => [
    'relationships' => '$type' //this says to use the field "type" instead of "__pclass"
  ],
],

I suppose this example means that the field $type still has to be the fully qualified php class name, so I'm not sure it is really that helpful anyway...

Just wanted to know if you guys have come across this feature request?

[jmikola]

The functionality you're requesting is roughly how discriminator fields are used in Doctrine ODM to support single collection inheritance. By default, a class name would be stored, but discriminator maps can also be defined in the PHP model in order to store shorter strings in the database field.

I suppose this example means that the field $type still has to be the fully qualified php class name, so I'm not sure it is really that helpful anyway...

In your example, the type field would effectively be treated like __pclass with two notable differences:

• type would presumably be a string instead of a BSON binary type used for __pclass
• During BSON decoding, the driver would leave the type class in place, in contrast to how __pclass gets omitted from the data passed to the bsonUnserialize() method.

I'd encourage you to look into BSON codecs, which are implemented in the PHP library. The __pclass and fieldPaths functionality will likely stick around in the extension for backwards compatibility, but we don't have plans to improve upon them further. The codec API allows for more control over BSON encoding and decoding since the logic can be implemented in PHP userland code.