[PHPCR-56] Support Hashmaps in fields Created: 26/Feb/12  Updated: 22/Oct/12  Resolved: 08/Oct/12

Status: Closed
Project: Doctrine PHPCR
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: David Buchmann Assignee: Lukas Kahwe
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
is referenced by PHPCR-43 Custom data type Closed


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.

Comment by David Buchmann [ 14/Apr/12 ]

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.

Comment by Lukas Kahwe [ 04/Oct/12 ]

see https://github.com/doctrine/phpcr-odm/pull/180

Generated at Thu Mar 05 06:45:57 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.