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 @Transient properties to PersistentEntity and use value defaulting for transient constructor properties #2985

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

mp911de
Copy link
Member

@mp911de mp911de commented Nov 21, 2023

We now maintain @Transient metadata in the mapping model to determine whether a transient property has been used in a Kotlin Data class, Record or plain Java class.

record MyRecord(String firstname, @Transient String lastname) {
}
data class MyDataClass(@Transient val firstname: String = "foo", @Transient val age: Int)

Entity instantiation populates properties with default values (null for object types, or primitive default values) so that Kotlin data classes can use defaulting.

Closes #1432
Closes #2942

mp911de and others added 4 commits November 4, 2024 14:26
We now ignore transient properties used in constructors. Regular transient properties default to the Java default values (null for object types, 0 for numeric primitives and so on).

Using transient properties allows leveraging Kotlin's defaulting mechanism to infer default values.

Record components can also be annotated with the Transient annotation to allow record construction. While this can be useful, we recommend using the Value annotation to use SpEL expressions to determine a useful value.
Add missing Override annotations, consistently use literal tags for boolean values.
@odrotbohm
Copy link
Member

Do we really need getTransientProperty(…)? I wonder what the use case is to actually look up those explicitly? Also, dies that mean that getProperty(…) only returns non-transient properties now?

One other thing we have to double-check is the expectations that client code using doWithProperties(…) had. So far, the callback was not involved for transient properties, simply because they haven't been captured at all. Unfortunately, this means that the code in those callbacks doesn't expect to be called for transient properties in the first place and doesn't guard against that case.

@mp911de
Copy link
Member Author

mp911de commented Nov 4, 2024

One other thing we have to double-check is the expectations that client code using doWithProperties(…) had

We never provided transient properties to callbacks via doWithProperties and I would not want to change that. Otherwise, a lot of code assumptions get broken.

Likely we don't need to expose getTransientProperty(…). This is merely used internally for the isTransient check.

Also, dies that mean that getProperty(…) only returns non-transient properties now?

getProperty never returned transient properties in the first place. It's intended to remain that way.

	public void treatsTransientAsNotExisting() {
		assertThat(getProperty(ClassWithReadOnlyProperties.class, "transientProperty")).isNull();
	}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
3 participants