Store a Map of Properties in a Node

Hi,

For a new functionality we are developing, we need to store a map of properties in a Node. This map won't be very large, between 5 and 10 Key-Value pairs.

I've been searching in the docs for something like that but it seems that it's not yet supported?
What options I have if I want to have this map of properties contained in a single property in a Node?

Thanks

What is the end goal of these map of properties? Are they relevant to the node that they are being stored in? Or are they intended to be extracted for use elsewhere?

Can you share a snippet of code showing an example of what you are trying to accomplish?

Hi @mckenzma,

The end goal of the properties map is to store the parameters of the query the user has made, both the key and the value (e.g.: if the query consists of 'country' as the key and 'UK' as the value, we want to store both).
The properties map will be later used to build a query and then execute it at anytime against the database. This way we want be able to "reuse" the same query over and over against updated data. So yes, it is inteded to be extracted for use elsewhere.

We are still designing the functionality so we don't have any code yet. I hope it's clear if not I can try to write up an example here.

Thanks!

P.D.: For now as a first approach we are storing the key-value pairs in a String but I don't think that's optimal in the long run

To use a graph to store a query we've got that modeled and built out as a .NET Standard Library (if only there was time to open source things!).

Not to overshare, but you're going to want to store those as separate nodes.
You can't store an object map as a single property on a node.

If you know the query specific props you COULD store the params as props on the node, and then manage splitting them out in the domain processing layer.

so if you have (:Query {theQuery:'MATCH (n) WHERE n.name = $name'})

You could do:

MERGE (qq:Query {theQuery:$myQuery})
SET qq += $myParamMap

where myParamMap is {name:'Sammy'}

Then when you read it out, you'd have to split your known query props, and then take the remainder as the neo4j query parameters.

The other way, is to store them as an attached node for each parameter along with it's value.

We store them as nodes, but that's because of other features designed into the tooling.

@mckenzma has worked with it as well and may have additional pro-cons for either implementation.

1 Like

@mrksph what stack are you using? I'm asking because I can potentially push out some of my .NET stuff to nuget. It stores queries, traces execution of them, and tracks a bunch of metrics for it.