CODEWITHSUNDEEP
scalacastingdnsresultset
virtualeyes
virtualeyes

Reputation: 11237

Scala Bean Coercion :: The Missing LINQ

Update

Play 2.0's Scala version will feature ANORM, which seems similar to Querulous in that both are JDBC wrappers and not ORMs. Here's ANORM query coercion at work with a parser combinator:

SQL("""
        select * from Country c 
        join CountryLanguage l on l.CountryCode = c.Code 
        where c.code = 'FRA';
    """
    ).as(
        str("name") ~< spanM(
            by=str("code"), str("language") ~< str("isOfficial") 
        ) ^^ { 
            case country~languages => 
                SpokenLanguages(
                    country,
                    languages.collect { case lang~"T" => lang } headOption,
                    languages.collect { case lang~"F" => lang }
                )
        } ?
    )

The multi-line query """ sql """ is nice, I like that, but the coercion, please, no ;-) In Groovy, bean coercion with the same query is a 1-liner:

List[Country] c = sql.rows("select * from country")?.collect{ it.toRowResult() as Country }

the null safe operator (?.might-be-null) in groovy is quite convenient, scala seems to require the Some() Option[] combo to deal with possible null outcomes. Do Scala coders like null handling in Scala?

I guess the general thrust of this post is: can Scala provide scripting language concision while retaining compiler type safe code? Given that Scala is perhaps more powerful/expressive than C# (unintentional flame), then a full blown Scala LINQ must be possible. Furthermore, since Scala straddles the functional and OO paradigms, then it must also be able to achieve Groovy level concision (for example, the 1-liner query-bean-coercion above).

If these assumptions are true, then why do the existing scala ORMs and jdbc wrappers require so much boilerplate compared to groovy and LINQ on C#? Obviously I am an idealist looking for bare bones DSLs where implementations are either incredibly concise, or closely mirror the underlying language they represent (as in LINQ-to-SQL).

Original

Have been taking a run through the various Scala ORMs (squeryl, daomapper, couple others will fill in later) and SQL helper frameworks (querulous so far)

Being new to Scala and strongly typed languages in general, one thing that leaps out at me is the need to specify the type (String, Int, etc.) of each column in every query result.

About to get on an overnight train here, but this struck me just now, so putting it out there (will add some examples when I get back online again to make this a bit of less of a ramble)

For now, a quick one from Querulous's readme on github:

val users = queryEvaluator.select("SELECT * FROM users WHERE id IN (?) OR name = ?", List(1,2,3), "Jacques") { row =>
  new User(row.getInt("id"), row.getString("name"))
}

While I understand that the compiler needs to know the type of every "object" you work with, it seems non-DRY to have to specify "row.getInt('id')" when the domain class itself already declares that id is of type Int.

So, coming from a fair degree of ignorance, I will ask, why do Scala ORMs and SQL helper frameworks not provide developers with an implementation model that allows for inferred or implicit result sets?

Just to put in context, I am coming from Grails, which has an, imo, excellent domain/validation model among other framework nice-to-haves, but suffers from dynamic language time wasting fat-finger typing (startup time is painful as well) which is why I am exploring Scala frameworks.

Upvotes: 1

Views: 320

Answers (1)

oluies
oluies

Reputation: 17831

See Scala Integrated Query as I understand it is scheduled to be integrated in the typesafe stack as Scala Language Integrated Connection Kit (SLICK)

enter image description here

Upvotes: 4

Related Questions