2013-08-14 6 views
8

Ich verwende derzeit Slick 1.x für den Zugriff auf MySQL innerhalb von playframework 2.1.3. Während Slick im Allgemeinen ziemlich gut aussieht, kann ich mir nicht vorstellen, wie repetitiv die Deklarationssyntax ist. Ich meine, einen Blick auf den folgenden Code haben:Wie kann ich vermeiden, Slick-Modell Erklärung Ausführlichkeit und Wiederholbarkeit

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 
} 

Es kann nicht richtig sein, dass, um einen einfachen Fall der Klasse zu haben und eine Zugriffsobjekt, werde ich jedes einzelne Feld dreimal erklären müssen. Gibt es eine Möglichkeit, diese fehleranfällige Wiederholbarkeit zu vermeiden?

aktualisieren: Natürlich ist eine Lösung für dieses Problem sollte unterstützen lesen und Schreiboperationen.

Antwort

1

Sie können Code-Generierung verwenden oder in der Zukunft: Geben Sie die Anbieter ein.

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

+1

Aus dem Thread: _ "Source-Code-Generation-basierte Typ-Provider werden wahrscheinlich mit kommenden Slick 2.1 später in diesem Jahr ausgeliefert." _ D. Dass sie nicht für die Produktion mit 1.x verwendbar sind. Code-Generatoren sind eine wirklich gute Möglichkeit, spröde Code zu erzeugen, aber fügen Sie nicht viel Beweglichkeit im Austausch. – keyboardsamurai

+0

Was macht Code Gen in Ihren Augen nicht agil? – cvogt

+0

Grundsätzlich löst es nur den ersten Schritt der Modellverwaltung. Du musst dich regenerieren und Veränderungen etc. verlieren. Es ist kein Muster, mit dem ich mich wohl fühle. Aber ich denke, bis 2.x Gold wird, muss dies tun. – keyboardsamurai

5

Sie könnten direkte Einbettung verwenden. Es ist eine experimentelle, Makro-basierte API, die Sie schreiben Ihre Tabellen wie diese können:

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

bearbeiten:

Docs sind hier: http://slick.typesafe.com/doc/1.0.1/direct-embedding.html

+1

Oh - nur diese von dem docs bemerkt ** ** „Die direkte Einbettung derzeit verfügt nicht über Einfügen von Daten.“ -, dass es unbrauchbar für mich macht. – keyboardsamurai

Verwandte Themen