CODEWITHSUNDEEP
playframework-2.0slick
Andrew Wheeler
Andrew Wheeler

Reputation: 213

Playframework with SLICK and 22 column restriction

I've been doing an evaluation of the Play framework and learning Scala which has been fun. Coming from java, the move to the Scala took a fair bit mental gymnastics, however I am now a fan.

I have a sizeable database already mapped using JPA and I was just going to continue to use this code (with hibernate) however this is not the best or recommended approach with Scala. So I started mapping some tables using SLICK but before going too far I realised that I would run into issues with Scala's restrictions on case classes and function parameters (no more than 22).

I find this completely baffling that a modern ORM would have this restriction. I don't have a problem with Scala having this restriction - after all who wants to pass 22 parameters to a function. So my question is : why design a library with this limit? Surely it should have been engineered to map to regular classes? I don't care if it even used reflection to get the job done.

I have seen the workarounds for this which require splitting case classes and recombining using an implicit conversion. But this is just a hack.

I guess if I want to continue to use Play then I should switch to Java and use JPA.

Upvotes: 4

Views: 1099

Answers (1)

lreeder
lreeder

Reputation: 12206

This strangely numbered limitation is most likely because the Scala programming language limits the max size of a tuples to 22, and tuples are a nice way to represent table rows. See Why are scala functions limited to 22 parameters? for more info. There has been some talk of removing this restriction in Scala 2.11 (and presumably in Slick), and there is an open issue to track it, but this has not happened as of recent 2.11 releases.

I am not a Slick developer, and I'm sure they could have created an ORM based on something without a limit like a List instead of Tuples. Here's my hypothesis for why it turned out that way.

  • Typesafe didn't want to build an ORM from scratch, so adapted Slick from ScalaQuery, which was one of the most stable and widely adopted ORM packages for scala.
  • The ScalaQuery author saw fit to use tuples as a key part of the design.
  • The ScalaQuery author felt tables with more than 22 columns are somewhat rare.
  • He felt projection of those tables which pull more than 22 columns are even more rare.
  • Typesafe is working toward removing the 22 limit from Tuples (and Functions), and doing this is necessary for Scala, and once this is done Slick will no longer have problem with 22+ column tables. Since the issue must be fixed in Scala, it makes more sense to do this than create a new ORM and work with the community to adopt it.

Upvotes: 4

Related Questions