Kotlin con JPA: l'inferno del costruttore predefinito

Come richiesto da JPA, le @Entityclassi dovrebbero avere un costruttore predefinito (non arg) per creare un'istanza degli oggetti quando vengono recuperati dal database.

In Kotlin, le proprietà sono molto convenienti da dichiarare nel costruttore principale, come nell'esempio seguente:

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

Ma quando il costruttore non arg viene dichiarato come secondario, richiede che vengano passati i valori per il costruttore primario, quindi per loro sono necessari alcuni valori validi, come qui:

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

Nel caso in cui le proprietà abbiano un tipo più complesso di un semplice Stringe Intnon siano annullabili, sembra del tutto negativo fornire i valori per loro, specialmente quando c'è molto codice nel costruttore e nei initblocchi primari e quando i parametri vengono utilizzati attivamente - - quando devono essere riassegnati attraverso la riflessione, la maggior parte del codice verrà eseguita nuovamente.

Inoltre, le valproprietà non possono essere riassegnate dopo l'esecuzione del costruttore, quindi si perde anche l'immutabilità.

Quindi la domanda è: come si può adattare il codice Kotlin per lavorare con JPA senza duplicazione del codice, scegliendo valori "magici" iniziali e perdita di immutabilità?

PS È vero che l'ibernazione a parte JPA può costruire oggetti senza costruttore predefinito?

A partire da Kotlin 1.0.6 , il kotlin-noargplug-in del compilatore genera costruttori predefiniti sintetici per le classi che sono state annotate con annotazioni selezionate.

Se usi gradle, l'applicazione del kotlin-jpaplugin è sufficiente per generare costruttori predefiniti per le classi annotate con @Entity:

buildscript {
    dependencies {
        classpath "org.jetbrains.kotlin:kotlin-noarg:$kotlin_version"
    }
}

apply plugin: "kotlin-jpa"

Per Maven:

<plugin>
    <artifactId>kotlin-maven-plugin</artifactId>
    <groupId>org.jetbrains.kotlin</groupId>
    <version>${kotlin.version}</version>

    <configuration>
        <compilerPlugins>
            <plugin>jpa</plugin>
        </compilerPlugins>
    </configuration>

    <dependencies>
        <dependency>
            <groupId>org.jetbrains.kotlin</groupId>
            <artifactId>kotlin-maven-noarg</artifactId>
            <version>${kotlin.version}</version>
        </dependency>
    </dependencies>
</plugin>

basta fornire i valori predefiniti per tutti gli argomenti, Kotlin diventerà il costruttore predefinito per te.

@Entity
data class Person(val name: String="", val age: Int=0)

vedere la NOTEcasella sotto la seguente sezione:

https://kotlinlang.org/docs/reference/classes.html#secondary-constructors

@ D3xter ha una buona risposta per un modello, l'altro è una nuova funzionalità di Kotlin chiamata lateinit:

class Entity() {
    constructor(name: String, age: Date): this() {
        this.name = name
        this.birthdate = age
    }

    lateinit var name: String
    lateinit var birthdate: Date
}

Lo useresti quando sei sicuro che qualcosa riempirà i valori in fase di costruzione o molto presto (e prima del primo utilizzo dell'istanza).

Noterai che sono cambiato agein birthdateperché non puoi usare i valori primitivi con lateinite anche loro per il momento devono essere var(la restrizione potrebbe essere rilasciata in futuro).

Quindi non una risposta perfetta per l'immutabilità, lo stesso problema dell'altra risposta al riguardo. La soluzione per questo sono i plugin per le librerie che possono gestire la comprensione del costruttore di Kotlin e mappare le proprietà sui parametri del costruttore, invece di richiedere un costruttore predefinito. Il modulo Kotlin per Jackson fa questo, quindi è chiaramente possibile.

Vedi anche: https://stackoverflow.com/a/34624907/3679676 per l'esplorazione di opzioni simili.

@Entity data class Person(/*@Id @GeneratedValue var id: Long? = null,*/
                          var name: String? = null,
                          var age: Int? = null)

I valori iniziali sono richiesti se si desidera riutilizzare il costruttore per campi diversi, kotlin non consente valori nulli. Quindi ogni volta che pianifichi ometti il ​​campo, usa questo modulo nel costruttore:var field: Type? = defaultValue

jpa non ha richiesto alcun costruttore di argomenti:

val entity = Person() // Person(name=null, age=null)

non c'è duplicazione del codice. Se hai bisogno di costruire un'entità e impostare solo l'età, usa questo modulo:

val entity = Person(age = 33) // Person(name=null, age=33)

non c'è magia (basta leggere la documentazione)

Non c'è modo di mantenere l'immutabilità in questo modo. Le valvole DEVONO essere inizializzate durante la costruzione dell'istanza.

Un modo per farlo senza immutabilità è:

class Entity() {
    public constructor(name: String, age: Int): this() {        
        this.name = name
        this.age = age
    }

    public var name: String by Delegates.notNull()

    public var age: Int by Delegates.notNull()
}

Ho lavorato con Kotlin + JPA per un po 'e ho creato la mia idea su come scrivere classi Entity.

Estendo leggermente la tua idea iniziale. Come hai detto, possiamo creare un costruttore privato senza argomenti e fornire valori predefiniti per le primitive , ma quando proviamo a usare altre classi diventa un po 'confuso. La mia idea è quella di creare un oggetto STUB statico per la classe di entità che si scrive attualmente, ad esempio:

@Entity
data class TestEntity(
    val name: String,
    @Id @GeneratedValue val id: Int? = null
) {
    private constructor() : this("")

    companion object {
        val STUB = TestEntity()
    }
}

e quando ho una classe di entità correlata a TestEntity posso facilmente usare lo stub che ho appena creato. Per esempio:

@Entity
data class RelatedEntity(
        val testEntity: TestEntity,
        @Id @GeneratedValue val id: Long? = null
) {
    private constructor() : this(TestEntity.STUB)

    companion object {
        val STUB = RelatedEntity()
    }
}

Naturalmente questa soluzione non è perfetta. È ancora necessario creare un codice di boilerplate che non dovrebbe essere richiesto. Inoltre c'è un caso che non può essere risolto bene con lo stub - relazione genitore-figlio all'interno di una classe di entità - in questo modo:

@Entity
data class TestEntity(
        val testEntity: TestEntity,
        @Id @GeneratedValue val id: Long? = null
) {
    private constructor() : this(STUB)

    companion object {
        val STUB = TestEntity()
    }
}

Questo codice produrrà NullPointerException a causa del problema dell'uovo di gallina - abbiamo bisogno di STUB per creare STUB. Sfortunatamente dobbiamo rendere questo campo nullable (o qualche soluzione simile) per far funzionare il codice.

Anche a mio avviso avere Id come ultimo campo (e nullable) è abbastanza ottimale. Non dovremmo assegnarlo a mano e lasciare che il database lo faccia per noi.

Non sto dicendo che questa sia la soluzione perfetta, ma penso che sfrutti la leggibilità del codice entità e le funzionalità di Kotlin (ad es. Sicurezza nulla). Spero solo che le versioni future di JPA e / o Kotlin rendano il nostro codice ancora più semplice e gradevole.

Come indicato sopra, è necessario utilizzare il no-argplug-in non fornito da Jetbrains.

Se stai usando Eclispe potresti dover modificare le impostazioni del compilatore di Kotlin.

Finestra> Preferenze> Kotlin> Compilatore

Attiva il no-argplugin nella sezione Plugin del compilatore.

Vedi: https://discuss.kotlinlang.org/t/kotlin-allopen-plugin-doesnt-work-with-sts/13277/10

Sono un nub me stesso ma sembra che tu debba esplicitare l'inizializzatore e il fallback a un valore nullo come questo

@Entity
class Person(val name: String? = null, val age: Int? = null)

Simile a @pawelbial, ho usato un oggetto compagno per creare un'istanza predefinita, tuttavia invece di definire un costruttore secondario, basta usare arg del costruttore predefiniti come @iolo. Ciò consente di evitare la necessità di definire più costruttori e di semplificare il codice (anche se concesso, la definizione di oggetti companion "STUB" non lo mantiene esattamente semplice)

@Entity
data class TestEntity(
    val name: String = "",
    @Id @GeneratedValue val id: Int? = null
) {

    companion object {
        val STUB = TestEntity()
    }
}

E poi per le classi che si riferiscono a TestEntity

@Entity
data class RelatedEntity(
    val testEntity: TestEntity = TestEntity:STUB,
    @Id @GeneratedValue val id: Int? = null
)

Come accennato da @pawelbial, questo non funzionerà laddove la TestEntityclasse "ha una" TestEntityclasse poiché STUB non sarà stato inizializzato quando viene eseguito il costruttore.

Queste linee di costruzione Gradle mi hanno aiutato:
https://plugins.gradle.org/plugin/org.jetbrains.kotlin.plugin.jpa/1.1.50 .
Almeno, si basa su IntelliJ. Al momento non funziona sulla riga di comando.

E ho un

class LtreeType : UserType

e

    @Column(name = "path", nullable = false, columnDefinition = "ltree")
    @Type(type = "com.tgt.unitplanning.data.LtreeType")
    var path: String

var var: LtreeType non ha funzionato.

Se hai aggiunto il plugin gradle https://plugins.gradle.org/plugin/org.jetbrains.kotlin.plugin.jpa ma non ha funzionato, è probabile che la versione non sia aggiornata. Ero alle 1.3.30 e non ha funzionato per me. Dopo l'aggiornamento alla versione 1.3.41 (più recente al momento della stesura), ha funzionato.

Nota: la versione di kotlin dovrebbe essere la stessa di questo plugin, ad esempio: ecco come ho aggiunto entrambi:

buildscript {
    dependencies {
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
        classpath "org.jetbrains.kotlin:kotlin-noarg:$kotlin_version"
    }
}