phpcr-odm
phpcr-odm copied to clipboard
[RFC] Collection Field Type
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/
...
you mean that phpcr-odm would automatically add a namespace and a naming scheme for them so that they can be grouped?
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.
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:
- it would mean that custom namespaces for those documents are not supported, which could be a problem when using e.g. a nt:file with some mixin to allow other children and then trying to put jcr:content into the group.
- we would need to create the node name from the field name plus a separator and then the actual node name to preserve the key. as with php arrays, we would have the problem that the concept of arrays and hashmaps is mixed together, so does unset($items[1]) reset the index of everything after 1 to not leave gaps or not?
- jcr sql queries would be difficult to write, you would need to know a lot of the phpcr-odm internals.
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?