Kotlin con JPA/Hibernate: nessun caricamento pigro senza `open`?

Question

La maggior parte Kotlin JPA codice di esempio si presenta

class Person(val name: String, val age: Int) { /* ... */ } 

o anche

data class Person(val name: String="", val age: Int=0) { /* ... */ } 

Ora, il Hibernate User Guide, e credo che anche molti altri ORM, statali che di solito vogliono creare proxy o comunque estendere la classe del modello, ma per consentire che in Kotlin la classe debba essere definita esplicitamente open. Questo è attualmente impossibile con le classi di dati e presumo, a giudicare dalla mia esperienza, che molte persone non ci pensano quando scrivono entità JPA in Kotlin.

Quindi, per venire alla mia domanda (questo è StackOverflow dopo tutto), è sufficiente fare

open class Person(val name: String, val age: Int) { /* ... */ } 

o sarebbe in realtà hanno a che fare

open class Person(open val name: String, open val age: Int) { /* ... */ } 

di non inutilmente ostacolare il ORM a fare il suo lavoro correttamente?
Se è davvero dannoso, dovremmo probabilmente proporre di aggiungere un avviso a IntelliJ IDEA, che se una classe ha un'annotazione @Entity, dovrebbe essere definita open.

Answer 1

Il tutorial che hai fornito specifica:

La classe entità deve avere un pubblico o protetto non-argomento del costruttore ... interfaccia non può essere designato come entità ... La classe di entità non deve essere definitiva . Nessun metodo o variabile di istanza persistente della classe entità può essere finale.

Le classi di Kotlin seguono la convenzione JavaBeans per setter/getter.

Se l'ORM ha requisiti di cui sopra, allora si hanno infatti specificare open sulla classe ei suoi metodi:

open class Person(open val name: String = "", 
        open val age: Int = 0) 

I valori di default per tutti i parametri del costruttore consentono Kotlin per generare un ulteriore vuoto costruttore. In alternativa è possibile fornire come un costruttore secondaria:

open class Person(open val name: String, open val age: Int) { 
    constructor() : this("", 0) 
} 

Nota che open val crea un campo finale privato e un getter aperta. Se ciò non è sufficiente, utilizza annotazioni come @JvmField open val name.

Gli ORM come quelli in uso hanno un attrito aggiuntivo con il codice Kotlin a causa degli schemi di progettazione discutibili che usano (come rendere tutto non-finale).

Una buona opzione è utilizzare un ORM specifico di Kotlin. Ad esempio, Exposed è supportato da JetBrains e utilizzato per alcuni dei suoi prodotti, che parla da solo. Un'altra opzione è Ebean che supporta ufficialmente Kotlin (grazie a @johnp)