Update show output column lists

[Hunterness]

• some 5.0 changes that had been missed
• add column type

Questions for reviewers:

• Operations: Please doublecheck I got the types right as well
• Docs: Should the type column be between name and description instead? (I followed what we had for transaction commands so if we want to change it we should also change there)
• Gem: Do we like the type names? Especially concerned with the LIST version as it doesn't really follow the cypher types cip (This is what we had for the show transactions command so if we want to change it I need to change there as well for consistency)

[neo-technology-commit-status-publisher]

Looks like you've updated the documentation!

Check out your changes at https://neo4j-docs-cypher-464.surge.sh

[gem-neo4j]

I started writing a CIP for a typeOf function this morning, where a function will be outputting the Type as a string. In the CIP I have written my initial recommendations to match how the type system is looking (and will most likely not be final), but part of that would be someone would go through the docs and make all the types consistent with the output of this eventual function (and probably update procedure signatures in the future).

The things that stick out to me here is the decision on LISTs and MAPs, I have suggested we do LIST and RECORD to match more closely the Cypher Types CIP. You have also used LONG, which is not in the type system as such, I guess this should be INTEGER. Then DATETIME might be good as ZONED DATETIME or LOCAL DATETIME?

It would be good to get those type CIPs finalised for this 😅

[Hunterness]

LONG, LIST and MAP is already there as such for the SHOW TRANSACTION command which is why I went with it like this though I agree that it differs from the Cypher types.

I find RECORD a bit odd for MAP (I know it comes from the GQL works and I should probably add a comment on the CIP about it anyway). We also as far as I'm aware don't currently call them record but map in docs so it feels even more odd to add RECORD here (https://neo4j.com/docs/cypher-manual/current/syntax/maps/).

The datetime is new and in this case it's zoned ones, I guess I can add that but at the moment we only refer to them as DATETIME in docs in general (for example https://neo4j.com/docs/cypher-manual/current/functions/temporal/#functions-datetime) so suddenly adding ZONED also feels odd if we don't do it everywhere?

It would be good to get those type CIPs finalised for this

It sure would XD

but part of that would be someone would go through the docs and make all the types consistent with the output of this eventual function

I wonder if it is better to be consistent with what we have for now, especially since it's ongoing work, and just update it when everywhere get's updated? Cause I can see users being confused by the ZONED or RECORD and then not finding any mentions of it anywhere else in the docs 🤔

Looking further at types:

The following data types are included in the property types category: Integer, Float, String, Boolean, Point, Date, Time, LocalTime, DateTime, LocalDateTime, and Duration.
The following data types are included in the structural types category: Node, Relationship, and Path.
The following data types are included in the composite types category: List and Map.

this do argue if favor of switching LONG to INTEGER at least, but against the RECORD one. It doesn't say anything around the inner types of list so those are still up for debate I guess 🤷

[gem-neo4j]

I agree about Map and have updated the CIPs as such :)

I think we can maybe keep as is and do one big docs update along with the implementation of the Cypher Types? Then everything is consistent at the same time

[ali-ince]

I think we missed documenting options field at the time, not sure if it's a separate PR or not though.

[Hunterness]

I decided it was a separate one XD

It's kinda part of a feature which feature flag is turned off and therefore undocumented. Maybe it should be documented separately excluding any mentions of the feature but it feels like a separate task from this PR

[ali-ince]

looks good to me.

[JPryce-Aklundh]

Looks great @Hunterness!
I just have a few suggestions.

As for your question, I don't think moving Type between Column and Description is necessary in this case. As far as I can see, the improvement would only be very marginal (e.g. where the value is BOOLEAN, it would maybe make sense for readers to know that before a description that says "if true" in front of it, but it is still coherent and comprehensible as it stands).

[Hunterness]

As for your question, I don't think moving Type between Column and Description is necessary in this case. As far as I can see, the improvement would only be very marginal

@JPryce-Aklundh The thing that triggered the question for me was the default labels in the description which is in the middle of the table, where previously they had been at the end. But I'm fine leaving it as is as well.