I have been using Play framework 2.0 for about 6 months, I have been wondering why they use so many boilerplate code to parse from my SQL query returns, like below:
case class Journal_accountDetail(amount: Double, states: Boolean)
val Journal_AccountParser: RowParser[Journal_accountDetail] = {
get[Double] ("amount") ~
get[Boolean] ("states") map({
case amount~states => Journal_accountDetail(amount,states)
})
}
Is it something that boost Play framework performance ??
anorm.SqlParser also provides convinent parser functions, like
.str
,.int
,.float
,.double
, ... instead of.get[String]
,.get[Int]
,.get[Float]
,.get[Double]
. Best regards.The parsing API can seem a bit tedious at first, but it's quite powerful when you start combining and re-using the parsers, and much less ugly than pattern matching in every function that returns an SQL result.
Imagine something like this:
To construct the
User
you need to parse a result with multipleJOIN
s. Rather than having one large parser, we construct one for each class in it's companion object:Note how I'm using the full table space in the parsers, in order to avoid column name collisions.
Altogether, this looks like a lot of code, but for each source file it's only a small footprint. And the largest benefit is that our
User
parser is quite clean despite it's complex structure. Let's say inUser
theaddress
is actuallyOption[Address]
. Then accounting for that change is as simple as changingAddress.parser
in theUser
parser to(Address.parser ?)
.For parsing simple queries, yes it does seem like a lot of boilerplate. But I'm quite thankful for the parsing API when it comes to parsing examples like the one above (and much more complex ones).