Use default values for primitive attributes when Graph properties are unset. #2348
Comments
spring-projects-issues
added
the
status: waiting-for-triage
|
Are you happen to have these properties defined as constructor parameters? Than this behavior is expected. It used to be a mapping exception but that prevents Kotlins explicit defaults from working: Non constructor properties should work. |
michael-simons
added
type: bug
michael-simons
changed the title
|
That has been actually more tricky than I thought, as we also want to support Kotlin default values (non JVM defaults, but explicit ones). But things should work now. Thanks again for the report. |
michael-simons
added a commit
that referenced
this issue
Aug 9, 2021
…erties are unset. This changes the behaviour in regards of default values for primitives attributes of domain objects: They have well known default values on the JVM and we should use them, even if the property is non-existent in the graph (materializing as literal null). People migrating from SDN+OGM rely on the behaviour. This change does not apply to attributes assigned via constructor arguments. Constructor argument don't have default values (in Java) and we try to avoid guessing as much as possible. In addition, it would also clash with actually possible default values in Kotlin data classes. The change cannot be done in `DefaultNeo4jConversionService` as originally planned, as the conversion service is of course unaware about the target of a converted value. This fixes #2348.
michael-simons
added a commit
that referenced
this issue
Aug 9, 2021
…erties are unset. This changes the behaviour in regards of default values for primitives attributes of domain objects: They have well known default values on the JVM and we should use them, even if the property is non-existent in the graph (materializing as literal null). People migrating from SDN+OGM rely on the behaviour. This change does not apply to attributes assigned via constructor arguments. Constructor argument don't have default values (in Java) and we try to avoid guessing as much as possible. In addition, it would also clash with actually possible default values in Kotlin data classes. The change cannot be done in `DefaultNeo4jConversionService` as originally planned, as the conversion service is of course unaware about the target of a converted value. This fixes #2348.
michael-simons
added a commit
that referenced
this issue
Aug 17, 2021
michael-simons
added a commit
that referenced
this issue
Aug 17, 2021
michael-simons
added a commit
that referenced
this issue
Aug 17, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am upgrading my existing application to sdn6. There's a
booleanfield in my entities that is not set for some of the nodes.Reading those nodes fails with
NullPointerExceptionwhen unboxing null to boolean.I tried to trace that problem and to me it seems that
DefaultNeo4jConversionServicehas extra handling for null-values (valueIsLiteralNullOrNullValue) and that causes that no converters are called.So the case cannot be caught through a custom converter. Is there another way to handle null-values gracefully?
This problem did not exist with OGM
The text was updated successfully, but these errors were encountered: