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

Way to ignore properties from delegate #459

Open
vladokvocka opened this issue Jun 2, 2021 · 5 comments
Open

Way to ignore properties from delegate #459

vladokvocka opened this issue Jun 2, 2021 · 5 comments

Comments

@vladokvocka
Copy link

Hi, consider following code:

data class Base(
    @JsonProperty("prop1") val prop1: String,
    @JsonProperty("prop2") val prop2: String
)

data class Specific(
    @JsonProperty("baseProps") val baseProps: Base,
    @JsonProperty("prop3") val prop3: String
) : Base by baseProps

When using objectMapper.writeValueAsString(specific), result JSON looks like this:

{
    "@type": "Specific",
    "baseProps": {
        "@type": "Base",
        "prop1": "value1",
        "prop2": "value2"
    },
    "prop1": "value1",
    "prop2": "value2",
    "prop3": "value3"
}

Is there a way to ignore all delegated properties from delegate Base without specifying every one of them using @JsonIgnoreProperties? Something like @JsonIgnoreDelegates("baseProps") would be great. The result should look like this:

{
    "@type": "Specific",
    "baseProps": {
        "@type": "Base",
        "prop1": "value1",
        "prop2": "value2"
    },
    "prop3": "value3"
}
@dinomite
Copy link
Member

dinomite commented Jun 5, 2021

Interesting idea, I think that we'd be able to do that with some changes in KotlinNamesAnnotationIntrospector.

@cowtowncoder
Copy link
Member

I would recommend caution wrt adding such logic in AnnotationIntrospector as it would sort of have to undo/redo quite a bit of logic to recreate inheritance hierarchy (or other processing to do cross-type introspection).
The main challenge is that AI is designed to be called on property-by-property basis which makes it difficult to do changes based on a set of properties.

It does sound something that would not necessarily Kotlin-specific (if I understand this correctly), so it could possibly be in databind.

One other thing to consider for now is that @JsonIncludeProperties would be little bit less work, to allow specifying only properties that are to be included.

@k163377
Copy link
Contributor

k163377 commented Apr 4, 2023

The limitations on Kotlin make it very difficult to fix this problem.
The details are summarized in the following comment.
#574 (comment)

If the following is implemented in Jackson, this problem may be solved.
FasterXML/jackson-future-ideas#28

@k163377
Copy link
Contributor

k163377 commented Mar 16, 2024

In response to comment from @sandwwraith, I have reviewed this issue again.

As for the requested feature, unfortunately I don't think it is important enough to introduce it into kotlin-module.

First of all, we have had a long time so far, and there does not seem to be a lot of support for this feature request.
Also, since there are not that many classes that would be defined this way, I think that customization using MixIn would be sufficient.

import com.fasterxml.jackson.annotation.JsonIgnore
import org.junit.jupiter.api.Test

interface I {
    val i: Int
}

data class Delegated(val p: I) : I by p

abstract class MixIn : I {
    @get:JsonIgnore
    abstract override val i: Int
}

class Temp {
    @Test
    fun test() {
        val dto = Delegated(object : I { override val i: Int = 1 })
        val mapper = jacksonObjectMapper().addMixIn(Delegated::class.java, MixIn::class.java)
        println(mapper.writeValueAsString(dto)) // -> {"p":{"i":1}}
    }
}

@cowtowncoder
Copy link
Member

I agree that the feature would need to be implemented in jackson-databind so filing an issue there would make sense. Not saying it would be likely to be implemented (this would be tricky to do), but that'd be the place.

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

No branches or pull requests

4 participants