@DynamicLabels generates non-parametrized query

[zakjan]

@DynamicLabels generates non-parametrized query with dynamic node labels REMOVE node:<oldLabels> SET node:<newLabels> (source code).

A non-parametrized query is generated even when there is no change in the dynamic labels, e.g. REMOVE node:LabelA SET node:LabelA for a node entity with dynamic label LabelA.

When the number of dynamic labels is greater than Cypher query cache size (default 1000), this leads into a query cache overflow and causes replanning of other well-parametrized queries.

Since Neo4j 5.26, can node labels can be parametrized in this query as REMOVE node:$($oldLabels) SET node:$($newLabels)?

Node labels from @Node annotation are perfectly fine to be formatted into the query as-is (non-parametrized), as they are ensured to be constants by Java. It's only @DynamicLabels which allow any string causing this issue.

[zakjan]

My colleague @garbybaby has tried to implement this in #3034. While it doesn't fulfill the purpose of parametrizing dynamic labels yet, it's worth as a showcase of what we're trying to achieve.

[meistermeier]

Hi, thanks you for pinging us again (and @garbybaby for the PR). I just forgot to answer after the PR was opened.
We will definitely have a look next week.
The problem I see with this, that's why it will take some time to evaluate, is that we cannot parameterize them all the time. Spring Data Neo4j is considered to support a wider range of Neo4j versions.

[zakjan]

This is a valid concern, this means that both non-parametrized and parametrized variants would need to be supported by the dialect selection.

[michael-simons]

I am adding support for it in Cypher-DSL (see comments on the PR).

One idea obviously is when we have that, to also add the ability to translate parameter values to static labels from older dialects, so that we can just always dynamic parameters from SDNs point of view.

[zakjan]

@michael-simons Thank you for the progress! I haven't realized Cypher DSL doesn't have support for label parametrization yet, it's good to see it coming.

[michael-simons]

This is coming in SDN 8. Working solution is on my desk. Quite happy about that.

[zakjan]

@michael-simons Happy to hear that, thank you!

What's the motivation for SDN major version bump, what kind of changes are expected for upgrading from SDN 7.4?

[michael-simons]

Hey,

the version bump is unrelated to this change.
It's just aligned with the Spring Data release train.
Also, we do did bump the Cypher DSL version from 2024.x to 2025.x, which would warrant a major bump in semver alone.
Because we need the latter for that feature, we are not going to backport it.

While there are breaking changes in Cypher DSL, there are non in SDN 8. We hope the Neo4j drivers team will get the driver major ready in time when the Spring release trains rolls, that's it.