Before I spend a bunch of time on a pullrequest... Is it a terrible idea to declare a generated ID a...

# spring

[diesieben07]

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?

[Czar]

I for one prefer ID immutable.

[diesieben07]

It can't be though, otherwise Hibernate will explode, right?

[Czar]

It won't, it uses reflection.

[fitzoh]

don’t things get a little messy w/ autogenerated id’s on the initial insert?

[fitzoh]

the id doesn’t exist until you insert it

[Czar]

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.

[diesieben07]

Yeah, but then you have a nullable id...

[fitzoh]

yeah, also gross

[diesieben07]

This is what I'd do:

class UserEntity(
    var username: String
) {
    @Id
    @GeneratedValue
    lateinit var id: UUID
}

[Czar]

Well, with hibernate nullable ID is a given anyway, so might as well make it explicit

[diesieben07]

I am not sure why it is. It is only nullable before you persist it.

[Czar]

yeah, a conundrum

[Pere Casafont]

@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

[diesieben07]

Which would cause the same issue with spring data 🙂

[Pere Casafont]

well, of course it would be about changing how spring data works in kt

[diesieben07]

Which is what my initial question is about ... 😄

[Pere Casafont]

yes, and I countersuggest delegates instead of lateinit

[Pere Casafont]

lateinit doesn't work on primitives

[diesieben07]

Yes, however lateinit is much cheaper at runtime when you don't have a primitive. So both should be supported.

[Pere Casafont]

agreed