RFC: Schema casting

[jails]

After some refactoring on data collection, it result the following in DocumentSet::_init() :

$this->_data = $schema->cast($this, $this->_data, compact('exists', 'pathKey'));
foreach ($this->_data as &$data) {
    $data = $schema->cast($this, $data, compact('pathKey', 'model'));
}

if we stick on tests, everything looks like working fine but it's kinda weird. DocumentSet need to manage two types of array.

Simple array :

array('4cb4ab6d7addf98506010000', '4cb4ab6d7addf98506010001');

And field based array :

array(
    array(
      'id' => '4cb4ab6d7addf98506010000'
    ),
   array(
      'id' => '4cb4ab6d7addf98506010001'
   )
)

To avoid edge effects what could be the best solution for this issue ? Reintroducing the DocumentArray with its own Document::__init() extending DocumentSet ? Or finding a way to dected passed datas to avoid having to use multiple classes ?

[nateabele]

Yeah, this is why I added DocumentArray. ;-) Do you want to re-add DocumentArray and make DocumentSet extend it?

[jails]

Yeah of course, but before I just wanted to show you this following refactoring of the schema casting :
jails@a209d15

Well if you don't like it, I'll re-add DocumentArray. Initially I tried to remove DocumentArray for the following reason.
When we deal with cascading relations you are intended to use the following syntax :

$object->myrelation = array(...);

myrelation can be an embeded relation but will also be a hasMany\hasOne or belongsTo relation. Since actually relations are not supported on MongoDB, the problem is not yet topical but the casting process will inspect the datas to make a choice beetween a DocumentSet, a DocumentArray or a Document instanciation. Imo this inspection will goes into a little more cumbersome process. Indeed the inspection will depend on the type of relation (if relevant), the pathkey and the type of the datas (it's a lot of check).

[nateabele]

Okay understood. Yeah, the refactoring makes sense (I'm guessing it's a BC break because of the change to cast()'s signature?). So you're saying with this refactoring, we can avoid re-adding DocumentArray?

[jails]

Yes the casting strategy in the above commit works on any type of data array without re-adding DocumentArray. Otherwise the BC break is not limited to the cast() 's signature. Indeed when wrap is set to true, the DocumentSchema->cast() will always return a Document or a DocumentSet (for making the recursivity casting works). You can see the difference in ExporterTest::testTypeCasting() where $result[] is now $result->.

The other "break" concern DocumentTest::testSetAndCoerceArray(). Before setting $doc->forceArray = false; returns an empty array. With this commit it will returns array('false') but I think tests will be clearer that my confused explanation ;-)

[nateabele]

Yeah I think the fix makes a lot of sense. Having forceArray = false map to forceArray = array(false) seems like a pretty sensible solution.