Skip to content

Refine customization of EntityInformation #3288

Closed
4 of 4 issues completed
Closed
4 of 4 issues completed
@JonasProgrammer

Description

@JonasProgrammer

Hi,
I currently have the problem of marking an entity as new, even though it has a non-null UUID as id. The basic idea is to use a null-object pattern with the special case of a new UUID(0, 0), rather handling Nullability.

Reading around spring-projects/spring-data-relational#1587 either Persistable or providing a custom EntityInformation is suggested. For my use-case, Persistable has the downside of clashing with data class definitions in Kotlin having a id member, which clashes with the getId function (though it does not satisfy the interface somehow...).

EDIT: Forgot to mention I am using Spring Boot 3.4.4, which, as far as I can tell, matches the version of spring-data-relation, spring-data-r2dbc, and the common shared stuff.

So I tried to go down the road of supplementing a R2dbcRepositoryFactoryBean with getEntityInformation overridden to return a delegate of the super call, overriding isNew to my liking. The factory bean does get instantiated once per repository, but the getEntityInformation method never gets called (both verified using breakpoints in the debugger). Returning a delegating subclass of R2dbcRepositoryFactory with a similar approach to its getEntityInformation method yielded the same result.

So when one would want to go down the rabbit hole of providing a custom implementation for EntityInformation, how does one actually do this properly?

Kind regards

--
Aside from that, as a meta question: We have the null/0-default hardcoded logic, Persistable as an intrusive way of doing things, and (presumably) EntityInformation working very low-level. Is there a specific reason, why something in between is unfeasable? I saw a EntityIsNewStrategy with implementations for the hardcoded null/0, and the persistable logic.
One could give the user the ability to supply something akin as beans. And while I get not going through a chain as in web filters, for example, for performance reasons, one could choose the best matching implementation from an ordered list, where each participant could implement a boolean supports(Class<?> domainType) or something.

Sub-issues

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions