Before I spend a bunch of time on a pullrequest......
# spring
d
Before I spend a bunch of time on a pullrequest... Is it a terrible idea to declare a generated ID as a
lateinit var
in a JPA entity? Right now it fails, because Spring Data's
isNew
check accesses the ID and expects null, this could be patched to allow for
lateinit
. Is that a good idea?
c
I for one prefer ID immutable.
d
It can't be though, otherwise Hibernate will explode, right?
c
It won't, it uses reflection.
f
don’t things get a little messy w/ autogenerated id’s on the initial insert?
the id doesn’t exist until you insert it
c
Yes, I have my entities like this:
class MyEntity(val id: Long? = null, ...)
When I create new one, its ID is null, when I persist it, hibernate sets the id to the generated value.
d
Yeah, but then you have a nullable id...
f
yeah, also gross
d
This is what I'd do:
Copy code
class UserEntity(
    var username: String
) {
    @Id
    @GeneratedValue
    lateinit var id: UUID
}
c
Well, with hibernate nullable ID is a given anyway, so might as well make it explicit
d
I am not sure why it is. It is only nullable before you persist it.
c
yeah, a conundrum
p
@diesieben07 your solution is good only with object-type ids; long and int are out of the equation, so imho the best thing here would be to use delegates
d
Which would cause the same issue with spring data 🙂
p
well, of course it would be about changing how spring data works in kt
d
Which is what my initial question is about ... 😄
p
yes, and I countersuggest delegates instead of lateinit
lateinit doesn't work on primitives
d
Yes, however
lateinit
is much cheaper at runtime when you don't have a primitive. So both should be supported.
p
agreed