Jak mogę uniknąć deklaracji modelu Slick i jego powtarzalności?

Obecnie używam Slick 1.x, aby uzyskać dostęp do MySQL w Playframework 2.1.3. Podczas gdy ogólnie funkcje Slicka wyglądają całkiem nieźle, nie mogę zawinąć głowy, jak powtarzalna jest składnia deklaracji. Chodzi mi rzucić okiem na poniższy kod:Jak mogę uniknąć deklaracji modelu Slick i jego powtarzalności?

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 
}

To nie może być prawda, że aby mieć prostą klasę obudowy oraz Object Access, będę musiał zadeklarować każdego pola trzykrotnie. Czy istnieje sposób na uniknięcie tego błędu podatnego na powtarzanie?

Aktualizacja: Oczywiście rozwiązanie tego problemu powinno ułatwić odczytywanie i pisać operacje.

Źródło

2013-08-14 keyboardsamurai

Można użyć generowanie kodu lub w przyszłość: dostawcy typu.

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

Źródło

2013-08-20 15:05:59 cvogt

Z wątku: _ "Dostawcy typu opartego na kodzie źródłowym prawdopodobnie pojawią się wraz z nadchodzącym Slick 2.1 jeszcze w tym roku.", Tzn. Nie można ich używać do produkcji z 1.x. Generatory kodów są naprawdę dobrym sposobem na stworzenie bardziej kruchego kodu, ale nie powodują większej zwrotności w zamian. – keyboardsamurai

co sprawia, że gen gen nie jest zwinny w twoich oczach? – cvogt

Zasadniczo to rozwiązuje pierwszy krok zarządzania modelem. Będziesz musiał zregenerować się i stracić zmiany itp. To nie jest wzór, który mi odpowiada. Ale myślę, że dopóki 2.x nie przejdzie na złoto, będzie musiał to zrobić. – keyboardsamurai

Można użyć bezpośredniego osadzania. Jest to eksperymentalny, makro oparte API, które pozwala pisać tabele tak:

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

edit:

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

Źródło

2013-08-14 06:19:46 drexin

oh - Właśnie zauważyłem tego od docs ** ** „Bezpośrednie osadzanie obecnie nie dysponują wstawiania danych.” - to sprawia, że nadaje się do użytku dla mnie. – keyboardsamurai

Jak mogę uniknąć deklaracji modelu Slick i jego powtarzalności?

Odpowiedz

Powiązane problemy