Add list or map to field

[clem]

How to add a list to an attribute:

MATCH(p:Person{name:'Tom Hanks'})
SET p.favoriteThings = ['rain drops', 'boxes without tops']
RETURN p

returns:

{
  "identity": 71,
  "labels": [
    "Person"
  ],
  "properties": {
"name": "Tom Hanks",
"favoriteThings": [
      "rain drops",
      "boxes without tops"
    ],
"born": 1956
  }
}

Note that the list can't even be heterogeneous, e.g. it can't have a mix of strings and numbers.

Generally the Neo4J documentation is pretty good, but there are definitely places where it lags and where it could use more examples or better explanation.

I think given where they are, they've done a commendable job.

[clem]

Yes, but it's harder to search for the roles.... if they are in a list...

I posted this about a real situation from the movies (but not in the sample Movie DB...): Alec Guinness and his 9 roles in "Kind Hearts and Coronets". I'm not sure what the schema choice should be:

How to search in properties of a relationship which has an array of values?

Here's a twisted question.... What if the movie is Kind Hearts and Coronets where Alec Guinness plays nine different roles at once? Here, a person creating the ACTED_IN relationship might decide (badly?) that the roles property should be in a list instead of creating multiple relationships with a single string for each role. (They might decide have nine relationships of the same type with different properties clutters things up.) CREATE (p:Person {name:'Alec Guinness', born : 1914}) CREATE…

[tideon]

Hello Andrew,

I get the idea that you have some official connection to the Neo4J company. Could you update the help file to reflect this piece of knowledge you added here. Because if you look at the manual about list, nowhere does it show how to assign to a field, nor does it explain the aspect of not being able to store complex structures, same goes for the maps. nowhere does the map page explain that it can't be added to a field. And that is extremely important to know.

I have read here more clear information about list & maps, than is contained in the manual. I have studied many applications / software packages and read many manual, but this manual is really written from an engineers point of view, and there is so much missing when things are explained.

I bought the O'Reilly book you guys published, but that reads more like a : look this is what the application can do, and not as a means to learn the Neo4j platform. I read it and it more felt like it was written to entice banks and large IT infrastructures to use your platform, so i didn't learn much other than what scenarios Neo4j would flourish in and how theoretically it could solve the problem.

As with this problem I spent two days all over the internet reading trying to figure out how to use List and maps, and here in these responses I got more clarity than the manual offers.

I really think Neo4j needs to get a dedicated person who's training is to write user manual, as they are skilled in taking a technical thing ( engineers language ) and turn it into a user manual.

To put things in perspective, I an self learning Linear Algebra at the moment and I am finding it easier to understand that than understand how to do simple things in neo4j once I read the manual, as the manual often leaves crucial things out. And a good example is list. In the manual it doesn't tell you how to assign it, it only uses the return clause to show that it is able to create it. And that is often so in the manual, return is used so often, but not the practical use.

Google says you are an engineer at Neo4J

[tideon]

Thank you Clem for this, this is so clear to understand.
I would like to ask Andrew to add this to the manual as a clear example. This is clearer than anything there right now. Your entire explanation.

[tideon]

Hello Andrew,

I was even on your blog reading about list, but there also I could not find anything from your post on list on how actually to asign it ot a field, and that maps and nested structures are not allowed. Even the manual doean't mention this crucial fact as far as I recall.

[andrew_bowman]

Hello,

Yes, I'm an employee at Neo4j.

I've passed along your feedback and linked the thread. While we do have the Expressions section in the docs that provides an example of list and map literals (and keep in mind that we can work with lists and maps as variables, so literal expressions don't always have to come into play when working with list properties), and documentation for the SET clause, I believe the Values and Types documentation seems very complex and tough to understand. I think there's certainly opportunity to make that clearer with some examples of what is allowed and what is not.

In addition the SET clause documentation seems like the right place to talk about what can and cannot be set as node properties, and some examples would absolutely be helpful here.

Thank you for your feedback.

[clem]

You can propose a change (which will be managed by git), and eventually it will get pushed through. I've proposed a few changes to Neo4J doc via git and they got (eventually) accepted. (If you click on the unhappy face and write something there, it doesn't get looked at too often.)

I don't know if you've ever been involved with a big development type system, but it's hard to get it right and there are so many places to get it wrong.

This is especially true for a tech writer who's very experienced with the material trying to imagine what a newbie might have trouble understanding. (I think I'm pretty good at it...)

You'll also see some gaps with APOC functions, because often they are wrappers around Java standard libraries which aren't very well explained and APOC documentation for those tend to parrot the Java documentation which also isn't very good.

I've looked at the documentation for TigerGraph and for Gremlin. Those two are far worse shape and far more confusing and lacking.

Language design and implementation is actually quite tricky. You probably don't appreciate how difficult it is nor how far it has come in 70 or so years.

The final thing I will say, is Graph DB's aren't easy.... I was involved in a company years ago trying to do this, and we just didn't have the software tools nor the hardware capability to do this. Neo4J is quite an achievement!

[tideon]

Hello Andrew,

That is exactly what I meant. I really struggle with your manual. I have been reading it for a year, and almost always I have to come here to ask questions like you see in this thread. The style used to write the manual doesn't allow you to see things in full use.

And added more exampel to SET would be a good idea. We need to really know what can and cannot work. This thread made me for th firt time understand more about what cannot be added to a field.

One major issue I encounter with the manual is that when i do a search it takes me out of the scope of where I am reading. So if you go to this page The Neo4j Cypher Manual v5 - Cypher Manual

and you search for list from the right hand corner. I shows you even things from APOC, it just overloads you with non-relevant things. I often just want to search within the scope I am in, so if I am in manual 4.2, I would like it to search in there only.

[tideon]

Hello Andrew,

Just for clarity, I appreciate that you are doing what you do, I have read your blog and now I also know you write for the manual. I saw a video on Youube explaining this exact phenomenon, in that if someone knows a subject extremely well, there brain fills in the blanks of what it thinks someone would already know, because the brain sees many of those things as nothing new.

So I am open to helping to update the manual with feedback and also write questions that aren't answered. Last year I figured out how the REGEX works, as the manual has next to no information, so that would be one of the things I would like to contribute, as it took me almost two weeks of trial and error to understand what NEO4J was allowing and not, as it isn't as straight forward as normal REGEX in python or in SUBLIME or Visual code

I will get back to you, as I have to figure out GIT, also one thing I would like to ask, is that the feedback button on the bottom of the page has the option to write text when you click the smiley face or frown, as i wanted to give detailed feedback on a page at times, but couldn't explain what would be better.

I would also like to send you video captures showing clear example to compare what me as a newbie would have needed to see sfor it to instantly click.

[clem]

BTW, if you're having trouble with regex (and who doesn't when it gets a bit hairy!)

try the regex debugger: https://regex101.com/

[johnmattgrogan]

Hi tideon,

In the cypher manual it does list the data types that can be assigned to properties. I've fallen into the trap of trying to make cypher act like python, and I've found for me this is usually a red flag that I may need to re think my design. The flexibility of having data stored as relationships rather than key / value pairs can make your life easier as the model gets more complex. However I understand every scenario has it's trade offs.

Values and types - Cypher Manual

[tms]

Hi Tideon,

I too came to Cypher and Neo4J about a year ago and have had similar "attunement" issues (I have deep OO/Python/Javascript/Smalltalk experience). I call the structure that you contemplate for gd.BankAccounts an OrderedDictionary -- a list where each element is a pair and where order is preserved. As others have suggested, I think you've inadvertently created what we EE's would call an "impedance mismatch" between your contemplated structure and the natural semantics of Neo4J.

I've found it helpful to draw the data structure on a piece of paper or whiteboard. When I did this just now, I drew a circle for "gd", and an arc to another circle that I labeled "BankAccount". I draw each property as a horizontal rectangle divided into left and right cells. The left contains the property name, the right contains the property value. For each BankAccount node, I added the following properties: name, accountCode, and accountNumber. I drew two instances of BankAccount (each a node), one for each element of your list. I connected those with a bidirectional "next/previous" relationship.

Now I transliterate that drawing into a Cypher query. I like to use the Neo4J browser (https://your.domain.name:7474) as a REPL so that I fiddle with it. I haven't tried it, but I think it looks something like:

MATCH (gd: Party)-[BANK_ACCOUNTS: LINK]->(abn_amro: BankAccount {name: "ABN-AMRO", accountInformation: "NL56 ABNA 123.456.789"})-[NEXT: LINK]->(ing: BankAccount {name: "ING", accountInformation: "123.456.789"}) RETURN gd

The advantage of doing it this way is that you gain all the power of Neo4J in managing these lists. In particular, each list can be queried and manipulated. After you've created a few thousand gd instances, it's going to be tedious if you find yourself needing to add an additional field to each BankAccount element and you've built out your original approach.

It's analogous to a design question that comes up in Python (and other OO languages) all the time -- when I want to model a dictionary of key-value pairs, do I use a dictionary or create a new class/object. Most languages (Cypher, Python, PHP, etc) have at least an implicit bias towards the answer to that question. In a language like C, Java, PHP and others, creating and then instantiating a new class is a heavyweight operation and might lead to the approach you've contemplated. In Neo4J/Cypher, creating nodes and relationships is MUCH easier.

One final thought that might help -- consider how you'd store this BankAccounts field in relational DB like MySQL. While it might be tempting to express it as, for example, a JSON string that is stored in a string-valued column (VARCHAR or whatever), that approach would give your DBAs apoplexy. If you were designing a SQL schema for this, you'd almost immediately start thinking about a separate "BankAccount" table, foreign keys, and joins. THAT is your tipoff that your best bet in Neo4J is promote the BankAccount property to a relationship named bankAccounts added to gd and then connecting instances of a BankAccount node in an list using instances of Relationship.

I hope this helps!