"it is an anorm type that it is not really convenient to use outside of your database access code."
Erem Wrote:
I think it approaches database access from a very interesting direction
Noel Welsh Wrote:
With ScalaQuery your queries can return case classes(case classes are just fancy tuples)
Drew Hamlett Wrote:
I just felt that the ORM way is ugly, bloated, and over complicated.
I would do:
case class Appointment(id: Long, name: String, detail:
Option[AppointmentDetail] = None)
case class AppointmentDetail(description: String, location:String)
Then write a parser for Appointment as
parser = get[Long]("id") ~ get[String]("name") map {
case id~name => Appointment(id, name)
}
then a parser for AppointmentDetail:
detailParser = get[String]("description") ~ get[String]("location") map {
case desc~loc => AppointmentDetail(desc,loc)
}
And compose them to get a full Appointment parser:
fullParser = parser ~ detailParser map {
case a~d => a.copy(detail = d)
}
> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/GVX-oiF6-8AJ.
>
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framewor...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.
--
Guillaume Bort
Guillaume Bort Wrote:
I would do:
case class Appointment(id: Long, name: String, detail:
Option[AppointmentDetail] = None)
case class AppointmentDetail(description: String, location:String)
Sadache Wrote:
On the same lines you could do
case class Calendar(appointment:AppointmentHeader)
case class AppointmentHeader(id: Long, name: String)
case class Appointment(header: AppointmentHeader, description: String, location:String)
Drew Hamlett said:
If you need 3 columns in one situation, 10
another time and 5 another time, hopefully your not going to write
different parsers for that.
I'd just do a Select *
You have more control on what the queries are doing. In a lot of cases they can be more optimized and specific to what you need.
So to clarify again: my view isn't that ANORM is a bad idea (I think it is a great idea). I simply feel that ANORM within the context of Play! seems out of place, as the philosophy that permeates the design of everything else (such as typed templates) negates the benefits that ANORM claims to provide if it leads you to use ANORM like an ORM (side-note: ANORM is Not an ORM). So far the discussions have revolved around
--You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/jltymUiinwwJ.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.