You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 #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.
The text was updated successfully, but these errors were encountered:
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 #1587 either
Persistable
or providing a customEntityInformation
is suggested. For my use-case,Persistable
has the downside of clashing withdata class
definitions in Kotlin having aid
member, which clashes with thegetId
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
withgetEntityInformation
overridden to return a delegate of the super call, overridingisNew
to my liking. The factory bean does get instantiated once per repository, but thegetEntityInformation
method never gets called (both verified using breakpoints in the debugger). Returning a delegating subclass ofR2dbcRepositoryFactory
with a similar approach to itsgetEntityInformation
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 aEntityIsNewStrategy
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.The text was updated successfully, but these errors were encountered: