2013-08-14 3 views
8

Attualmente sto utilizzando Slick 1.x per accedere a MySQL all'interno di playframework 2.1.3. Mentre generalmente le caratteristiche di Slick sembrano piuttosto buone, non riesco a capire come sia ripetitiva la sintassi della dichiarazione. Voglio dire dare un'occhiata al seguente codice:Come evitare la dichiarazione del modello di Slick verbosità e ripetitività

case class User 
(id: Option[Long] 
, firstName: String 
, lastName: String 
, email: String 
, password: String 
, status: String 
, createDate: Long = Platform.currentTime 
, firstLogin: Option[Long] 
, lastLogin: Option[Long] 
, passwordChanged: Option[Long] 
, failedAttempts: Int = 0 
) 

object User extends Table[User]("USER") { 
    def id = column[Long]("id", O.PrimaryKey, O.AutoInc) 
    def firstName = column[String]("firstName", O.NotNull) 
    def lastName = column[String]("lastName", O.NotNull) 
    def email = column[String]("mail", O.NotNull) 
    def password = column[String]("password", O.NotNull) 
    def status = column[String]("status", O.NotNull) 
    def createDate = column[Long]("createDate", O.NotNull) 
    def firstLogin = column[Long]("firstLogin", O.Nullable) 
    def lastLogin = column[Long]("lastLogin", O.Nullable) 
    def passwordChanged = column[Long]("passwordChanged", O.Nullable) 
    def failedAttempts = column[Int]("failedAttempts", O.NotNull) 

    def * = id.? ~ firstName ~ lastName ~ email ~ password ~ status ~ createDate ~ firstLogin.? ~ lastLogin.? ~ passwordChanged.? ~ failedAttempts <>(User.apply _, User.unapply _) 
    def autoInc = * returning id 
} 

Non può essere giusto, che, al fine di avere una semplice classe caso e un oggetto di accesso, dovrò dichiarare ogni campo tre volte. C'è un modo per evitare questa ripetitività incline agli errori?

Aggiornamento: Naturalmente una soluzione a questo problema dovrebbe sostenere leggere e scrivere operazioni.

risposta

1

È possibile utilizzare la generazione di codice o nel futuro: tipo provider.

Vedi https://groups.google.com/d/msg/scalaquery/Pdp3GTXsKCo/O0e3JLXAaK8J

+1

Dal thread: _ "I provider di tipi basati sulla generazione di codice sorgente verranno probabilmente spediti con Slick 2.1 più avanti quest'anno." _ Cioè non sono utilizzabili per la produzione con 1.x. I generatori di codice sono un ottimo modo per produrre codice più fragile, ma non aggiungono molta agilità in cambio. – keyboardsamurai

+0

cosa rende il codice gen non agile nei tuoi occhi? – cvogt

+0

Fondamentalmente risolve solo il primo passo della gestione del modello. Dovrai rigenerare e perdere le modifiche, ecc. Non è un modello con cui mi trovo a mio agio. Ma suppongo che fino a quando 2.x diventerà oro, questo dovrà essere fatto. – keyboardsamurai

5

È possibile utilizzare l'incorporamento diretto. Si tratta di una sperimentazione, API macro-based che consente di scrivere le tabelle in questo modo:

@table("COFFEES") case class Coffee(
    @column("COF_NAME") name: String, 
    @column("SUP_ID") supID: Int, 
    @column("PRICE") price: Double 
) 
val coffees = Queryable[Coffee] 

modificare:

Docs sono qui: http://slick.typesafe.com/doc/1.0.1/direct-embedding.html

+1

Oh - appena notato questo dalla documentazione ** ** "La costruzione diretta attualmente non dispongono di inserimento dei dati." - che lo rende inutilizzabile per me. – keyboardsamurai