Bloom not seeing correct property type listed in Browser

[seangrant82]

Problem: When a property type is set to Long, Bloom sees it (and all other types as string)

Description: I loaded my data and set the property type to be an integer using the toInteger function but when trying to have Bloom resize the Nodes to the range of data in that property, it see that integer property as a string not a `Long'

Screenshot of browser showing type for raised_amount_usd for node Round:

Screenshot of type Bloom is reporting in RuleBased symbology dropdown:

Steps to reproduce:

1. Load attached data using following command: LOAD CSV WITH HEADERS FROM "file:/rounds.csv" AS line MERGE (:ROUND {raised_amount_usd:toInteger(line.raised_amount_usd)})
2. Issues following command to ensure field is set to Long (this is done because the LOAD_CSV will make the property a dual type ([Long],[String]) when using the toInteger function): MATCH (n:ROUND) SET n.raised_amount_usd = toInteger(n.raised_amount_usd) RETURN n.raised_amount_usd
3. Issue following command to view if type is Long: call db.schema.nodeTypeProperties
4. Open Bloom and create a new Perspective by searching for ROUND node
5. Try to apply a rule-based symbology to change the size of the node to be based on the raised_amount_usd

Bloom will not let you because it thinks it is a string

Versions

• Neo4j db: 4.04
• Neo4j Browser: 4.0.8
• Neo4j Desktop 1.2.8
• Bloom: 1.3.1

Sample Data: rounds.zip

[anutan76]

Following your steps (except for the first one where toINT had to be replaced with toInteger) on a new database, I am able to see the property set in Bloom as an Integer and can set a rule. See below. Could you try your steps on a new database to just work with your sample data and let us know what you find? Thanks for reporting and your detail here.

[anutan76]

Oh, and the only difference in setup was that I was using Neo4j 4.0.3, but I see the property returned as Long by call db.schema.nodeTypeProperties, so I'm assuming the slight difference in database version is not a factor here. Bloom uses this procedure as well.

[seangrant82]

@anutan76 so creating a fresh database and running through my steps works. Here is why I suspect I see a discrepancy in my other database:

I had created a new database and ran this command without converting toInteger on first import. I then deleted all node and relationships then adjusted LOAD_CSV to have toInteger to reimport. When removing all nodes/rels, the propertyKeys ARE NOT deleted.

• So I suspect there is a link or something somewhere that is holding on to that original type of string despite setting it toInteger later (step 2) and only way to get rid of that is to delete entire database since you cannot remove propertyKeys in Neo4j (I was told this is a known limitation)

I should have a chance tonight to test this theory later tonight but to reproduce you could follow same steps (remove toInteger from LOAD_CSV in step 1) then delete all nodes/rel then try the steps

[ckanz]

@seangrant82 thanks for the detailed issue report! Please note that perspectives in Bloom do not automatically update when the underlying graph changes. If you created the perspective when the property datatype for raised_amount_usd was still a string and updated the data in the graph later, the perspective will not reflect those changes automatically. For those changes to be visible in Bloom, you can either create a new perspective or delete and re-create the affected categories in the perspective (in your case the "ROUND" category).

[seangrant82]

@ckanz thanks for the information. I can confirm that either creating a new perspective or deleting the Category then re-adding will indeed show the datatype change. I will note this in my workflow. This is indeed not a defect and this issue can be closed

Are there plans to make Bloom more dynamic to be able to understand the underlying database changed?

[ckanz]

@seangrant82 thanks for letting us know this worked for you.

Regarding future plans, we are investigating how to make it easier to update perspectives when the underlying graph has changed as this a common problem for our users.