Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add null value handling for kotlin TypesAdapters #110

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

mikeyshean
Copy link

PR for #109

@djensen47
Copy link

djensen47 commented Feb 12, 2020

@macisamuele @martinbonnin @cortinico Any thoughts on this PR?

We spent a day and a half debugging this issue and @mikeyshean discovered that toJson needs to handle null values otherwise it triggers an issue in Moshi thinking there is a nesting problem and exception gets thrown by Moshi.

@macisamuele
Copy link
Collaborator

macisamuele commented Feb 13, 2020

@mikeyshean thank a lot for the contribution 🎉

The pr looks sane to me, but I need some time to verify it.
It looks surprising that we haven't face this issue before.

Something that for sure I'll ask is to have testing coverage over the change and ideally a unit test in samples/junit-test that ensures no further regressions around this.

Copy link
Collaborator

@macisamuele macisamuele left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned in the comment before we do need to have testing coverage over this change as a regression on this might lead again to the same bug.

I tried to play around to re-create a case similar to the one in #109 but I was not successful.

@@ -60,7 +60,7 @@ internal class LocalDateAdapter : XNullableJsonAdapter<LocalDate>() {
override fun fromNonNullString(nextString: String): LocalDate = LocalDate.parse(nextString, formatter)

override fun toJson(writer: JsonWriter, value: LocalDate?) {
value?.let { writer.value(it.format(formatter)) }
value?.let { writer.value(it.format(formatter)) } ?: writer.nullValue()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather suggest to have concrete implementations dealing only with the "not-nullable" case and having XNullableJsonAdapter taking care of the null handling.

Something like

internal abstract class XNullableJsonAdapter<T> : JsonAdapter<T>() { 
    abstract fun fromNonNullString(nextString: String): T
    abstract fun toJsonNonNull(writer: JsonWriter, value: T)
    ...
}

This allows to focus the attention of nullable in the class related to nullable and to the T type encoding in the related adapter class

@cortinico cortinico added this to the 2.0.0 milestone Mar 5, 2020
@klaszlo8207
Copy link

Any news on this?

@djensen47
Copy link

Sorry, the project we were using this on was canceled. @klaszlo8207 feel free to pick up this PR and add a regression test to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants