Details
-
Type:
New Feature
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Labels:None
Description
we should have an annotation to have multivalue properties be hashmaps, that is arrays with custom keys that get preserved. there are 3 options:
- two multivalue fields with keys and values respectively. see i.e. https://github.com/symfony-cmf/symfony-cmf/pull/140 (another workaround can be to use the @PostLoad and @PreUpdate hooks to split/merge the arrays)
- serialize the array into a string field
- child nodes (performance penalty). they would need to be in a special namespace to be identifyable and have a special format. a node for key-value is a lot. if you want a document with a specific name, you should use child documents directly, not a hashmap with document entry.
Issue Links
- is referenced by
-
PHPCR-43
Custom data type
-
Activity
David Buchmann
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Description |
we should have an annotation to have multivalue properties be hashmaps, that is arrays with custom keys that get preserved. there are 3 options: * two multivalue fields with keys and values respectively. see i.e. https://github.com/symfony-cmf/symfony-cmf/pull/140 * serialize the array into a string field * child nodes (performance penalty). they would need to be in a special namespace to be identifyable and have a special format. a node for key-value is a lot. if you want a document with a specific name, you should use child documents directly, not a hashmap with document entry. |
we should have an annotation to have multivalue properties be hashmaps, that is arrays with custom keys that get preserved. there are 3 options: * two multivalue fields with keys and values respectively. see i.e. https://github.com/symfony-cmf/symfony-cmf/pull/140 (another workaround can be to use the @PostLoad and @PreUpdate hooks to split/merge the arrays) * serialize the array into a string field * child nodes (performance penalty). they would need to be in a special namespace to be identifyable and have a special format. a node for key-value is a lot. if you want a document with a specific name, you should use child documents directly, not a hashmap with document entry. |
Lukas Kahwe
made changes -
Lukas Kahwe
made changes -
| Priority | Major [ 3 ] | Minor [ 4 ] |
Lukas Kahwe
made changes -
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
Lukas Kahwe
made changes -
| Status | Resolved [ 5 ] | Closed [ 6 ] |
This list may be incomplete, as errors occurred whilst retrieving source from linked applications:
- Request to http://www.doctrine-project.org/fisheye/ failed: Error in remote call to 'FishEye 0 (http://www.doctrine-project.org/fisheye/)' (http://www.doctrine-project.org/fisheye) [AbstractRestCommand{path='/rest-service-fe/search-v1/crossRepositoryQuery', params={query=PHPCR-56, expand=changesets[-21:-1].revisions[0:29],reviews}, methodType=GET}] : Received status code 503 (Service Temporarily Unavailable)
I gave the hashmaps some more thought. I think the reason JCR (and thus PHPCR) do not have hashmaps is because an unstructured node basically /is/ a hashmap. It has fields with string names and values of various types.
I think for the ODM, the best approach would be to have a @Hashmap mapping that is a special case of @Child. The value is an array that is mapped to a child node with the name of the field. This even allows to map nested arrays, fields that contain an array are just added as child node with that name. (the only thing i see here: we lose the order as children and properties are handled different).
When loading, the child node (and nested children) are mapped to array, or the propertycollection thing we use for multivalue, if that can handle keys.
i think this would be the most flexible approach and should not even be very difficult. when you store large nested arrays here, it becomes a bit slow but i think that would be a design flaw to use deep nested arrays as odm fields anyways.
the other options i see is adding the array_keys/values split workaround into the odm directly, but that only handles flat arrays and converts all values to string whereas the child node would keep DateTime, int, float, boolean and stream types as well. or we could serialize the array into a string property. but that feels yuk.