doctrine / phpcr-odm

Doctrine PHPCR ODM
http://www.doctrine-project.org/projects/phpcr-odm.html
MIT License
183 stars 96 forks source link

[RFC] Collection Field Type #715

Open dantleech opened 8 years ago

dantleech commented 8 years ago

I wonder if it would be possible to create a field type which would map a collection of child nodes to the property.

$image1 = new Image();
// ...
$geolocation1 = new Geolocation();
// ...
$page = new Page();
$page->title = "My Homepage";
$page->images = [ $image1, $image2 ];
$page->geolocations = [ $gelolocation1, $geolocation2, ... ];

The difference between this and the @Children mapping is that these children would be directly related to the property, and stored in PHPCR as follows:

my-page/
    title: My Homepage
    some-ns:image-0/
        ...
    some-ns:image-1/
        ...

    some-ns:geolocation-0/
        ...
    some-ns:geolocation-1/
        ...
dbu commented 8 years ago

you mean that phpcr-odm would automatically add a namespace and a naming scheme for them so that they can be grouped?

dantleech commented 8 years ago

Yeah, and perhaps add an annotation similar to @Children which filters the nodes and preserves the array keys.

I have basically gotten this working using @Children and a pre-persist subscriber:

https://github.com/symfony-cmf/content-type/pull/10/files#diff-b0f1a29ae3945b9bacfc82b0b991d60bR72

But array keys are not preserved, and I guess it might be a useful feature of PHPCR-ODM in general.

dbu commented 8 years ago

in our application, i used naming patterns for specific children to group them. i think it could indeed be useful to support this specifically. some limitations i see:

dantleech commented 7 years ago

it would mean that custom namespaces for those documents are not supported

Not sure I understand the problem? In the case of nt:file you would never have a @Collection of jcr:content. The case is more that any existing user-land node types would need to be permissive, and indeed they already need to take into account phpcrclass etc?

we would need to create the node name from the field name

In my current implementation array keys are not preserved (array_values is used). I guess one option would be to have a flag to define that behavior.

jcr sql queries would be difficult to write

Well, child() queries would not need to know anything about the child's node-name. In which cases would you need to?