Skip to content

Possibly support @Transient fields for Kotlin data classes without separate persistence constructor #449

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

Closed
pmaedel opened this issue Sep 7, 2020 · 2 comments
Labels
status: declined A suggestion or change that we don't feel we should currently apply

Comments

@pmaedel
Copy link

pmaedel commented Sep 7, 2020

The necessity to provide a separate persistence constructor for kotlin data classes with @Transient properties seems odd to me.

data class Fruit(
    @Id
    val id: Long? = null,
    val treeId: Long,
    val ripeness: Ripeness,
    @Transient
    val joinedTree: Tree? = null
) {

    @PersistenceConstructor
    constructor(
        id: Long?,
        treeId: Long,
        ripeness: Ripeness
    ) : this(
        id = id,
        treeId = treeId,
        ripeness = ripeness,
        joinedTree = null
    )
}

I would think it should be possible to exclude a @transient field during mapping for which default value is defined?

@mp911de
Copy link
Member

mp911de commented Sep 8, 2020

Thanks for raising a ticket. Improving @Transient property handling for constructor properties is indeed worth considering. Until that's in place, we should add @Value support so the object creation can spawn a null value which removes the need for an additional persistence constructor. See #450.

@mp911de mp911de added the status: declined A suggestion or change that we don't feel we should currently apply label Sep 9, 2020
@mp911de
Copy link
Member

mp911de commented Sep 9, 2020

We discussed the issue with our team and concluded that opening persistence constructors for transient properties contributes to ambiguity. The strict behavior allows for exact reasoning what's happening. Language features such as Kotlin's defaulting mechanism allow for graceful defaults. For now, we recommend using @Value("null").

@mp911de mp911de closed this as completed Sep 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: declined A suggestion or change that we don't feel we should currently apply
Projects
None yet
Development

No branches or pull requests

2 participants