Spring Data Graph: Map pairs as node properties?

[ractive]

Hello graphistas

We get json data back from a web app and we'd like to store the relevant parts of it in a @NodeEntity. We are currently following the approach to flatten the deep JSON structure to a flat Map<String, Object>, where the keys are converted to a dotted notation.

{
  "foo" : {
    "bar": 1,
    "baz": 2
  }
}

is converted to a Map like

"foo.bar" => 1
"foo.baz" => 2

in an entity like

@NodeEntity
public class MyEntity {
  private Map<String, Object> propertiesToStore;
  ...
} 

We now would like to store the key-value pairs of this propertiesToStore field directly as node properties. Any ideas how this could be implemented with Spring Data Graph?

Or are there even simpler or alternative approaches to store a JSON structure in a node with Spring Data Graph without using a Map as a field?


Best regards,
James

[MichaelHunger]

Right now there is no native support for storing maps in neo4j. You could register a spring converter that converts it to a json string and back again (or to another serialized form).

There is also the possibility to store the map directly as properties of the node? Perhaps prefixed with "foo." as in your example.

You might want to look into the source code of spring data graph and field-accessor-factories. Those allow you to register custom handlers for fields (like a Map<String, Object>) and handling write and read operations to this field.

It would be really cool if you could try that. If you need any hints just ping me. Probably create a JIRA ticket for that and let's continue to discuss there.

Thanks

Michael

[ractive]

I'll check out the field-accessor-factories you mentioned as this sounds very promising. I'll let you know how I'm proceeding with it.

[MichaelHunger]

Cool, looking forward to your solution. For the storage of the individual properties it might be useful to reuse PropertyFieldAccessor and/or ConvertingNodePropertyFieldAccessor probably just extract their functionality to a separate, reusable class.

[ractive]

I could not find a way to register an own FieldAccessorFactory implementation. I opened this JIRA ticket for that.

Just an idea...
I maybe useful to have a Map<String, Object> property be bound to its own referenced node. So maybe the following...

@NodeEntity
public class Person {
    private String name;

    @RelatedTo(type="has")
    Map<String, Object> address;
}

person.address.put("ZIP", 8000);
person.address.put("City", "Zürich"); 

...could create two nodes:
[Person]---(has)--->[address]

where the person node had a "name" property and the address node has the properties "ZIP" and "City" from the map.

This would keep something of the dynamic nature of neo4j.

The background of this: We must persist a lot of graphical information of entities that is not needed in the business layer, but must only be persisted and reached back to the UI again. This graphical information is part of a json document with quite a complex structure. Now instead of denormalizing this structure and creating many (from the backend point of view) useless entity classes, we would like to put this information dynamically in a flat map. This map would be stored ideally in its own node.

What do you think about such a dynamic component in SDG? Could there be other approaches to store key/values dynamically?

[MichaelHunger]

Hi,

you should be able to "register" FieldAccessorFactories by overriding NodeDelegatingFieldAccessorFactory and override the method createAccessorFactories.

But probably there should be a simpler way to register those, I'm not sure.

Interesting to use @RelatedTo for that, I'm a bit leaning towards a custom annotation? (Or probably none).

I've also thought about the solution you're proposing.

What one could do is to have the default-inlined solution for normal Maps and when using @RelatedTo then it is a separate node.

I'd like to have such a dynamic approach being supported in SDG.

I'm not sure about using a generic Map structure. Probably just using a neo4j Node or a SDG-MapNode or a simple PropertyContainer would be enough? For a Map you have to support all the operations of the Map interface some of which don't fit so well in this context (and it would have to be a managed Map anyway whose content must be reflected in the graph on any change)

Michael