Photo credit It’s been awhile since I wrote a Cypher Sleuthing post, but I’m back with a new one! This time, I’m going to show you how to find the data types of properties in Neo4j. I frequently want to find out the data type of a property so that I can map it in an application (in Java). I can never remember off the top of my head, and when I Google the question, the results are often outdated (here’s the answer post, but the syntax is old).

Photo credit I’ve recently been playing around with a JDK data set that details the historical library changes of the versions of Java, and with the release of Java 17 today (September 14!), I thought it would be a good time to explore this data set a bit more with others. I invite you to join me and to continue with additional exploration and projects! The data set is pulled from a Marc Hofman’s Github repository for the Java Almanac that also feeds a web browser version for the javaalmanac.

From part 1 introducing Cypher dates and formats to part 4 where we combined duration functions and temporal components to translate amounts in one unit to another unit, we have covered a lot of ground in this series! Filling in the gaps, part 2 showed us how to truncate dates for searches and use durations for adding/subtracting amounts of time, and part 3 gave us an intro to temporal components and translations within component groups.

Photo credit *Updated Dec 15, 2021 My previous part 1, part 2, and part 3 posts on this topic introduced Cypher dates, translated formats to the Cypher-supported ISO 8601 format, calculated durations, accessed components, and translated durations to certain values. If you read those, then this post is the next post showing how to convert durations across component categories. If you haven’t read the previous posts leading up to this one, feel free to catch up (recommend at least Part 3 as this post’s prequel) - though it isn’t required.

*Updated Dec 9, 2021 My previous part 1 and part 2 posts on this topic introduced Cypher dates, translated formats to the Cypher-supported ISO 8601 format, calculated durations, and measured lengths of time. If you read those, then this post is the next step with Cypher dates on date components, component translations, and duration conversions. If you haven’t read parts 1 or 2, feel free to catch up - though this post doesn’t require the previous ones.

*Updated Dec 9, 2021 My previous part 1 post on this topic introduced Cypher dates and translated a few other date formats to the Cypher-supported ISO 8601 format. If you read that, then this post is the next step with Cypher dates that covers durations and more. If you haven’t seen part 1, feel free to catch up - though this part 2 doesn’t necessarily require reading part 1. :)

No matter what database, programming language, or webpage you might be using, dates always seem to cause headaches. Different date formats require calculations between application date pickers in user-friendly formats and system dates in backend devices and data sources. Then, programming languages each have their own libraries and structures for dealing with dates, too. This concept in the Neo4j ecosystem isn’t any less complex with Cypher (a graph query language) date formats, the APOC library date functions/procedures, and countless possible integration tools/APIs for data import and export.

I was recently working on one of our developer guides (the CSV import guide) and came across some Cypher I needed to fine-tune in the CASE statement on that page. I had some trouble finding the correct syntax, so I reached out to some Cypher experts to get some help. As it turns out, I was looking at the Cypher CASE statement the wrong way and misunderstood its structure and design.

Why is it that some query syntax seems to run faster than another when there is very little difference between the statements? Sometimes, queries will invoke what is called the eager operator in order to maintain consistent operations and avoid conflicting data changes. It still leaves the question, though, of what does this eager operation do differently and why would it be important enough to specifically avoid in certain situations?