update params display to show new params setting

[praveenag]

neo4j> :param firstName => "Bruce"
neo4j> :param lastName "Wayne"
neo4j> :param alias: "Batman"
neo4j> :params
:param alias          => "Batman"
:param firstName      => "Bruce"
:param lastName       => "Wayne"
:param thisAssignment => "Works"
neo4j> :param hello => 23
neo4j> :param goodbye => "23"
neo4j> RETURN $hello, $goodbye;
+-------------------+
| $hello | $goodbye |
+-------------------+
| 23     | "23"     |
+-------------------+

1 row available after 11 ms, consumed after another 1 ms
neo4j> :params
:param alias          => "Batman"
:param firstName      => "Bruce"
:param goodbye        => "23"
:param hello          => 23
:param lastName       => "Wayne"
:param thisAssignment => "Works"

[lutovich]

@praveenag review completed. Made a comment about AbstractMap.SimpleEntry.

Couple things to think about (maybe already planned for future PRs?):

• how would user define a temporal or spatial param?
• will listing of temporal and spatial params include type so that they are visually different form strings?

[lutovich]

I think it is better to create a simple class with String and Object fields instead of using very verbose AbstractMap.SimpleEntry<String, Object> everywhere.

[praveenag]

You'd create temporal and spatial parameters using functions similar to the usage in queries ie: point({x:1, y:2})
About printing Spatial and Temporal types we based on @apcj excellent direction decided to use toString. I believe he'll be taking this discussion forward.

[lutovich]

I'm very much against using toString(). Java driver provides no explicit guarantees on the toString() format. Cypher shell has it's own requirements on how parameters should be formatted and thus should take care of the formatting. Please see the following two links for reasons why toString() is not the best choice: one & two

[praveenag]

Yea I'm with you on that. But thats the interim decision.